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 <mobileip-archive@odin.ietf.org>; 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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <vasosv@yahoo.com>
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: <ronyoung@americasm01.nt.com>


--- jspilot899827 <jspilot899827@fgrpublications.com>
wrote:

<HR>

<HTML>
<HEAD>
<TITLE></TITLE>
</HEAD>
<BODY>
<P>FGR Publications - <A
href="http://www.editorschoicereviews.com/issuecurrentnonaol.htm">The
Desktop Observer</A><BR>
<BR>
We need Book, Software, Product, Restaurant,
Resort &amp; Movie Reviewers - see below<BR>
<BR>
<A
href="http://www.editorschoicereviews.com/ccindexpage.htm">
Increase your GPA in one semester or receive
a 100% refund!</A><BR>
<BR>
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. <BR><BR>
CLOSEOUT PRICE ON NAME BRAND COMPUTERS<BR>
<BR>
$289 Refurbished Dell, Compaq &amp; 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.<BR>
<BR>
<A href="http://www.editorschoicereviews.com/app">
BOOK,SOFTWARE &amp; PRODUCT REVIEWERS NEEDED</A><BR>
<BR>
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.<BR>
<BR>
WE NEED Ebook authors - We pay 50% royalties.
<BR>
<BR>
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<BR>
<BR>
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.<BR>
<BR>
Visit the web site below and scroll down
to the &quot;We need ebook authors&quot;
section.<BR>
<BR>
<A
href="http://www.editorschoicereviews.com/ccindexpage.htm">Here
is the web site</A>.<BR>
<BR>
*******************************************************************************<BR>
<BR>
Today's Sponsor - Cut your water heating
bills in half! <A
href="mailto:cathy@fgrpublications.com?Subject=tankless">Click
here</A> for more info<BR><BR>
<BR>
*******************************************************************************<BR>
FGR Publications has been operating on the
Internet since 1997. <BR>
We never have and never will engaged in the
practice of SPAM or unsolicited<BR>
email. From time to time we will acquire
opt-in list only under the rules that we<BR>
are the only buyers of such a list. We will
then send an introductory<BR>
message such as this one you received from
us. This is vital for you and us<BR>
as it allows you to get off this list and
it will allow us to retain only the <BR>
true opt-in subscribers. You can feel safe
that it is in good hands. Again, <BR>
we strongly apologize for any inconvenience
this message has caused you, but on <BR>
the other hand you can now feel assured that
your removal request will be granted.<BR>
<BR>
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.<BR>
*******************************************************************************<BR>
<BR>
</P>
</BODY>
</HTML>



__________________________________________________
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 <mobileip-archive@odin.ietf.org>; 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 <FY3146FT>; Thu, 1 Mar 2001 06:29:11 -0500
Message-ID: <D0BFB433B390D411A6B500B0D07C53A1121C83@flarionmail.lab.flarion.com>
From: George Tsirtsis <G.Tsirtsis@flarion.com>
To: "'James Kempf'" <james.kempf@sun.com>, mobile-ip@sunroof.eng.sun.com
Cc: "'mipv6-handoff@sunroof.eng.sun.com'"
	 <mipv6-handoff@sunroof.eng.sun.com>,
        "'mobile-ip@marvin.corpeast.baynetworks.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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <FY3146FT>; Thu, 1 Mar 2001 06:29:11 -0500
Message-ID: <D0BFB433B390D411A6B500B0D07C53A1121C83@flarionmail.lab.flarion.com>
From: George Tsirtsis <G.Tsirtsis@flarion.com>
To: "'James Kempf'" <james.kempf@sun.com>, mobile-ip@sunroof.eng.sun.com
Cc: "'mipv6-handoff@sunroof.eng.sun.com'"
	 <mipv6-handoff@sunroof.eng.sun.com>,
        "'mobile-ip@marvin.corpeast.baynetworks.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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <behcet.sarikaya@usa.alcatel.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <msubbara@cisco.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: gistration revocation
Message-ID: <20010301124438.A3810@cisco.com>
References: <DFF2EFB82ADBD311B4BB00508B6F0C5C02B1F389@il27exm03.cig.mot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <DFF2EFB82ADBD311B4BB00508B6F0C5C02B1F389@il27exm03.cig.mot.com>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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 <behcet.sarikaya@usa.alcatel.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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 <behcet.sarikaya@usa.alcatel.com>
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/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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 <behcet.sarikaya@usa.alcatel.com>
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/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; 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 <tom.wang@mail.com>
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: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; 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 <tom.wang@mail.com>
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: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; 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 <tom.wang@mail.com>
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: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; 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 <tom.wang@mail.com>
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: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; 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 <tom.wang@mail.com>
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: <tom.wang@mail.com>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; 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 <tom.wang@mail.com>
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: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; 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 <tom.wang@mail.com>
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: <tom.wang@mail.com>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 1 Mar 2001 17:13:33 -0500 (EST)
From: "Sandy Thuel" <thuel@lucent.com>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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: <B9CFA6CE8FFDD211A1FB0008C7894E46027F445C@bseis01nok>
References: <B9CFA6CE8FFDD211A1FB0008C7894E46027F445C@bseis01nok>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.corpeast.baynetworks.com>;
          Thu, 1 Mar 2001 16:30:22 -0500 (EST)
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <FZ1PF0WZ>; Thu, 1 Mar 2001 15:30:00 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E4351C70F@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: "'Michael Thomas'" <mat@cisco.com>, Hemant Chaskar <hchaskar@hotmail.com>
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: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [seamoby] Hierarchical MIP, QoS, and Handoff</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Sounds like a =
no-brainer to me. The handoff signaling was the question and it looks =
like an ICMP solution has emerged? </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">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)?</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I really care more =
about the function than the WG or the protocol choosen - pick =
one.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">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. </FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Extremely counter to =
this is the investment each party has made in existing signaling =
solutions. </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">With a start from =
scratch mentality I would put in an IP header as I feel that it is a =
network layer function.</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Glenn</FONT>
</P>

<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Michael Thomas [SMTP:mat@cisco.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, March 01, 2001 12:33 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Hemant Chaskar</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Hesham.Soliman@era.ericsson.se; james.kempf@sun.com; =
mobile-ip@marvin.corpeast.baynetworks.com; =
seamoby@diameter.org</FONT></P>

<P><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: [seamoby] Hierarchical MIP, QoS, =
and Handoff</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">I don't see how this fundamentally =
changes</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">anything that James brought up. It =
still has to go</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">end to end, and it's still touching =
every router</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in between MN and CN. </FONT>
</P>

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

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; Mike</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hemant Chaskar writes:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Regarding the issue of =
round-trip latency in programming QoS forwarding </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; treatment along new path =
after change in CoA:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; This is intrinsic drawback =
of OPWA model of resource reservation of RSVP. In </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; the worst case, one =
round-trip time will include traversals of four wireless </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; links. This happens when =
both CN and MN are mobile.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Note that this drawback is =
eliminated in the approach to QoS signaling based </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; on including QoS Object in =
hop-by-hop options extension header along with </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; binding messages =
(draft-chaskar-mobileip-qos-00.txt). This draft was </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; presented in SD and =
revised version (01) will be submitted soon.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Hemant</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; =
_________________________________________________________________</FONT>=

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Get your FREE download of =
MSN Explorer at <A HREF=3D"http://explorer.msn.com" =
TARGET=3D"_blank">http://explorer.msn.com</A></FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>;
          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 <mobile-ip@SMALLWORKS.COM>;
          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: <E14YbBL-0007xc-00@csp01.csci.unt.edu>
From: Dist-Simulation2001 <swim99@cs.unt.edu>
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: <swim99@cs.unt.edu>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>


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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; Thu, 1 Mar 2001 15:29:41 -0800 (PST)
From: "Marco Zennaro (PATH)" <zennaro@PATH.Berkeley.EDU>
To: mobile-ip <mobile-ip@smallworks.com>
Subject: unsubscribe mobile-ip
Date: Thu, 1 Mar 2001 15:29:28 -0800
Message-ID: <NEBBJJCCGLALMGEPONMCGEGHCGAA.zennaro@path.berkeley.edu>
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: <zennaro@PATH.Berkeley.EDU>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <sebastn@attglobal.net>
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: <D0BFB433B390D411A6B500B0D07C53A1121BA6@flarionmail.lab.flarion.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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; 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 <mon@oracle.com>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: aa <mobile-ip@smallworks.com>
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: <mon@oracle.com>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>

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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <seamoby@diameter.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T5202fb13dbac12f25715a@davir04nok.americas.nokia.com>;
 Wed, 28 Feb 2001 19:42:07 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
 id <FWSXVBXT>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <seamoby@diameter.org>; 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 <seamoby@diameter.org>; 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 <T5202fb13dbac12f25715a@davir04nok.americas.nokia.com>;
 Wed, 28 Feb 2001 19:42:07 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <FWSXVBXT>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <seamoby@diameter.org>; 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 <behcet.sarikaya@usa.alcatel.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <seamoby@diameter.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <FV8XLT2A>; Wed, 28 Feb 2001 23:35:20 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBB0@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <seamoby@diameter.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <FV8XLT2A>; Wed, 28 Feb 2001 23:35:20 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBB0@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <seamoby@diameter.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <behcet.sarikaya@usa.alcatel.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <seamoby@diameter.org>; 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 <seamoby@diameter.org>; 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 <FV8XLT2A>; Wed, 28 Feb 2001 23:35:20 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBB0@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <seamoby@diameter.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <FV8XLT2A>; Wed, 28 Feb 2001 23:35:20 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBB0@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <seamoby@diameter.org>; 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 <mat@cisco.com>
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 <behcet.sarikaya@usa.alcatel.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <seamoby@diameter.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <FV8XLT2A>; Wed, 28 Feb 2001 23:35:20 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBB0@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <duvallmark@hotmail.com>
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: <F7btmWxT1OdpGOjXZ1t000016dc@hotmail.com>
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: <duvallmark@hotmail.com>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>

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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; Thu, 1 Mar 2001 23:02:39 -0500 (EST)
From: Zhongren Arnold Cao <zrcao@bigfoot.com>
To: mobile-ip <mobile-ip@smallworks.com>
Subject: unsubscribe mobile-ip
Date: Thu, 1 Mar 2001 23:04:17 -0500
Message-ID: <IIEIIEHBBGGPFEEMMEMDGEJFCBAA.zrcao@bigfoot.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 IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <NEBBJJCCGLALMGEPONMCGEGHCGAA.zennaro@path.berkeley.edu>
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: <zrcao@bigfoot.com>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <subas_bastola@hotmail.com>
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: <F179IIzQtO9vXLsdAef00004019@hotmail.com>
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: <subas_bastola@hotmail.com>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>

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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <B0000918101@fsnt.future.futsoft.com> 
          for <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>;
          Fri, 2 Mar 2001 15:55:50 +0530
Reply-To: prachimp <prachimp@future.futsoft.com>
From: Prachi Pande <prachimp@future.futsoft.com>
To: mobile-ip <mobile-ip@smallworks.com>
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: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>;
          Fri, 2 Mar 2001 10:54:36 +0530 (IST)
Message-ID: <127a01c0a2d9$834f2920$1eae7ac0@cisco.com>
From: "M.Sreenivasa Kiran" <mkiran@cisco.com>
To: mobile-ip <mobile-ip@smallworks.com>
References: <IIEIIEHBBGGPFEEMMEMDGEJFCBAA.zrcao@bigfoot.com>
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: <mkiran@cisco.com>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>;
          Fri, 2 Mar 2001 10:54:36 +0530 (IST)
Message-ID: <127b01c0a2d9$83726890$1eae7ac0@cisco.com>
From: "M.Sreenivasa Kiran" <mkiran@cisco.com>
To: mobile-ip <mobile-ip@smallworks.com>
References: <F179IIzQtO9vXLsdAef00004019@hotmail.com>
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: <mkiran@cisco.com>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <B0000918935@fsnt.future.futsoft.com> 
          for <mobile-ip@standards.nortelnetworks.com>;
          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 <mobile-ip@standards.nortelnetworks.com>;
          Fri, 2 Mar 2001 17:11:45 +0530
Reply-To: shankarv <shankarv@future.futsoft.com>
From: Shankar V <shankarv@future.futsoft.com>
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: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; Thu, 1 Mar 2001 22:06:30 -0800 (PST)
From: "Marco Zennaro (PATH)" <zennaro@PATH.Berkeley.EDU>
To: mobile-ip <mobile-ip@smallworks.com>
Subject: unsubscribe mobile-ip
Date: Thu, 1 Mar 2001 22:06:15 -0800
Message-ID: <NEBBJJCCGLALMGEPONMCOEHJCGAA.zennaro@path.berkeley.edu>
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: <zennaro@PATH.Berkeley.EDU>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; Fri, 2 Mar 2001 14:29:50 +0800
Message-ID: <001d01c0a2e4$7c98b640$088c10ac@dell>
From: Brenda <ybrenda@starnet.gov.sg>
To: mobile-ip <mobile-ip@smallworks.com>
References: <NEBBJJCCGLALMGEPONMCGEGHCGAA.zennaro@path.berkeley.edu>
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: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; Fri, 2 Mar 2001 00:27:36 -0600 (CST)
Received: by TMOEXH3 with Internet Mail Service (5.5.2650.21) id <FQARGCX7>;
          Fri, 2 Mar 2001 08:25:17 +0200
Message-ID: <B5C9EABE741FD411B68D00508B956AA4641BDC@MAILMAN>
From: "ALI OZDEMIR (NP-NS)" <ali.ozdemir@turkcell.com.tr>
To: "'mobile-ip@smallworks.com'" <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: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>



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

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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; 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 <berioli@zeus.nt.op.dlr.de>
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: <berioli@zeus.nt.op.dlr.de>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <MOBILE-IP@marvin.baynetworks.com>;
          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 <F5XCZG7G>;
          Fri, 2 Mar 2001 09:25:39 +0100
Message-ID: <91A311FF6A85D3118DDF0060080C3D8201931428@lat3721.lannion.cnet.fr>
From: AUVRAY Sebastien FTRD/DMI/CAE <sebastien.auvray@rd.francetelecom.fr>
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: <sebastien.auvray@rd.francetelecom.fr>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>

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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <seamoby@diameter.org>; 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 <seamoby@diameter.org>;
          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 <F1J9B31L>;
          Wed, 28 Feb 2001 20:42:15 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBAB@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'James Kempf'" <james.kempf@sun.com>,
        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: <Hesham.Soliman@era.ericsson.se>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>


> (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 <mobileip-archive@odin.ietf.org>; 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 <MOBILE-IP@marvin.baynetworks.com>;
          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 <MOBILE-IP@standards.nortelnetworks.com>;
          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 <MOBILE-IP@standards.nortelnetworks.com>;
          Fri, 2 Mar 2001 12:56:10 +0200 (EET)
From: Dionisios Gatzounas <dgat@intracom.gr>
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: <dgat@intracom.gr>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; Fri, 2 Mar 2001 12:04:22 +0100
Message-ID: <001601c0a309$02e5c660$821d513e@CATALUNYA>
From: Oscar de Luis <oscar.de.luis@upcnet.es>
To: mobile-ip <mobile-ip@smallworks.com>
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: <oscar.de.luis@upcnet.es>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>unsubscribe=20
mobile-ip<BR><BR></FONT></DIV></BODY></HTML>

------=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>;
          Fri, 2 Mar 2001 12:38:23 +0100
Message-Id: <v03007803b6c53719eee5@[193.204.209.162]>
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: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>






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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>;
          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 <F62SZHBY>;
          Fri, 2 Mar 2001 12:54:48 +0100
Message-ID: <A3B90A029310D41198A700508BCF8EB202B6FB0A@eestqnt103.es.eu.ericsson.se>
From: "Evaristo-Jose Camarero (ECE)" <Evaristo-Jose.Camarero@ece.ericsson.se>
To: "'mobile-ip@smallworks.com'" <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: <Evaristo-Jose.Camarero@ece.ericsson.se>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>

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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>; Fri, 2 Mar 2001 08:41:36 -0500 (EST)
Message-ID: <003a01c0a31e$c6a7b580$b1b656d1@1e3wl>
Reply-To: Frank Walker <fwalker@bocaperformance.com>
From: Frank Walker <fwalker@bocaperformance.com>
To: mobile-ip <mobile-ip@smallworks.com>
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: <fwalker@bocaperformance.com>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@smallworks.com>; 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 <mobile-ip@smallworks.com>;
          Fri, 2 Mar 2001 15:33:23 +0100
Message-Id: <v03007808b6c55fec88b8@[193.204.209.162]>
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: <wnk@fub.it>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>






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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Mar 2001 18:44:35 -0500 (EST)
Date: Fri, 2 Mar 2001 18:44:38 -0500 (EST)
From: Steven Glass - Solaris Software <Steven.Glass@Sun.COM>
Subject: [mobile-ip] Mobile-IP list woes - STOP AND READ!!!
To: mobile-ip@sunroof.eng.sun.com
Message-ID: <Roam.SIMC.2.0.6.983576678.16633.glass@purol.east>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Mar 2001 19:33:33 -0500 (EST)
Date: Fri, 2 Mar 2001 19:33:37 -0500 (EST)
From: Steven Glass - Solaris Software <Steven.Glass@Sun.COM>
Subject: [mobile-ip] mobile-ip@sunroof.eng.sun.com -- OK to post!
To: mobile-ip@sunroof.eng.sun.com
Message-ID: <Roam.SIMC.2.0.6.983579617.9859.glass@purol.east>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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) <majordomo>
        # 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):  

        <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>


    Email is being archived, so no worries, but it wont be accessible from
outside of Sun until later (which means the header List-Archive:
<http://playground.sun.com/mobile-ip/> 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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri,  2 Mar 2001 17:00:36 -0800 (PST)
Date: Fri, 2 Mar 2001 17:00:36 -0800 (PST)
From: Youngjune Lee Gwon <gyj@dcl.docomo-usa.com>
X-Sender: gyj@fridge.docomo-usa.com
To: IETF Mobile-IP Working Group <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] New I-D: draft-gwon-mobileip-l3mp-mipv4-00.txt
Message-ID: <Pine.BSI.4.05L.10103021658350.293-100000@fridge.docomo-usa.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <pcristea@epcc.ed.ac.uk>
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: <pcristea@epcc.ed.ac.uk>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <seamoby@diameter.org>; 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 <seamoby@diameter.org>; 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 <mat@cisco.com>
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: <B9CFA6CE8FFDD211A1FB0008C7894E46027F445C@bseis01nok>
References: <B9CFA6CE8FFDD211A1FB0008C7894E46027F445C@bseis01nok>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <seamoby@diameter.org>; 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 <seamoby@diameter.org>; 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 <seamoby@diameter.org>; 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 <T520223d95aac12f256081@davir03nok.americas.nokia.com>;
 Wed, 28 Feb 2001 15:47:02 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <FWSVH6M2>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <seamoby@diameter.org>; 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 <seamoby@diameter.org>; 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 <seamoby@diameter.org>; 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 <seamoby@diameter.org>; 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 <T52022655faac12f25715a@davir04nok.americas.nokia.com>;
 Wed, 28 Feb 2001 15:49:45 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <FWSX4951>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <seamoby@diameter.org>; 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 <seamoby@diameter.org>; 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 <seamoby@diameter.org>;
          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 <F1J9B31L>;
          Wed, 28 Feb 2001 20:42:15 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBAB@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'James Kempf'" <james.kempf@sun.com>,
        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: <Hesham.Soliman@era.ericsson.se>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>


> (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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <seamoby@diameter.org>; 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 <seamoby@diameter.org>; 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 <seamoby@diameter.org>; 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 <T5202fb13dbac12f25715a@davir04nok.americas.nokia.com>;
 Wed, 28 Feb 2001 19:42:07 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <FWSXVBXT>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <seamoby@diameter.org>; 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 <seamoby@diameter.org>; 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 <mat@cisco.com>
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 <behcet.sarikaya@usa.alcatel.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <pgkd@whomail.net>
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: <pgkd@whomail.net>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>

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

<html>

<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dwindows-=
1252">
<meta name=3D"GENERATOR" content=3D"Microsoft FrontPage 4=2E0">
<meta name=3D"ProgId" content=3D"FrontPage=2EEditor=2EDocument">
<title>FREE Computer With Merchant Account Setup</title>
</head>

<body>

<center>
<p><b>COMPLETE CREDIT CARD PROCESSING SYSTEMS FOR YOUR BUSINESS=2E INTERNE=
T -  HOME
BASED -  MAIL ORDER -  PHONE ORDER</b></p>
<p><b>Do you accept credit cards? Your competition does!</b></p>
<p>&nbsp;</p>
<p>Everyone Approved - Credit Problems OK!<br>
Approval in less than 24 hours!<br>
Increase your sales by 300%<br>
Start Accepting Credit Cards on your website!<br>
Free Information, No Risk, 100% confidential=2E<br>
Your name and information will not be sold to thrid parties!<br>
Home Businesses OK!  Phone/Mail Order OK!<br>
No Application Fee, No Setup Fee!<br>
Close More Impulse Sales!<br>
<br>
</p>
<div align=3D"center">
  <table border=3D"0" cellspacing=3D"0" width=3D"85%">
    <tr>
      <td width=3D"100%">
        <p align=3D"center"><b><font face=3D"Times New Roman" size=3D"5" c=
olor=3D"#CC0000">Everyone Approved!</font></b></p>
        <p><b><font face=3D"Times New Roman"> Good Credit or Bad!&nbsp; 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 &quot;n/a&quot; in the box=2E<br>
<br>
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<br>&nbsp;</font></b>
        </p>
      </td>
    </tr>
  </table>
</div>
<table border=3D"10" cols=3D"3" width=3D"385">
  <tbody>
    <tr>
      <td align=3D"center" bgColor=3D"#990000" width=3D"119"><b><font colo=
r=3D"#ffff00" face=3D"Arial,Helvetica" size=3D"3">Service</font></b></td>
      <td align=3D"center" bgColor=3D"#990000" width=3D"160"><b><font colo=
r=3D"#ffff00" face=3D"Arial,Helvetica" size=3D"3">Industry
        Standard</font></b></td>
      <td align=3D"center" bgColor=3D"#990000" width=3D"66">
        <p align=3D"center"><b><font color=3D"#ffff00" face=3D"Arial,Helve=
tica" size=3D"3">US</font></b></p>
      </td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Site
        Inspection</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$50 - $75</fo=
nt></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Shipping</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$50 - $75</fo=
nt></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Warranty</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$10 Per Month=
</font></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Sales
        Receipts</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$10 - $50&nbs=
p;</font></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Fraud
        Screening</font></b></td>
      </center>
    <td align=3D"middle" width=3D"160">
      <p align=3D"left"><font size=3D"2"><b>$=2E50 - $1=2E00</b><br>
      <b>Per Transaction</b></font></p>
    </td>
<center>
<td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica" size=3D=
"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Amex Set
        Up</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$50 - $75</fo=
nt></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">24 Hour&nbsp;Help
        Line</font></b></td>
      <td align=3D"middle" width=3D"160"><b><font size=3D"2">$10 Month</fo=
nt></b></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">FREE</font></b></td>
    </tr>
    <tr>
      <td bgColor=3D"#ffff00" width=3D"119"><b><font face=3D"Arial,Helveti=
ca" size=3D"2">Security
        Bond</font></b></td>
      <td align=3D"middle" width=3D"160"><font size=3D"2"><b>$5000- $10,00=
0</b><br>
        <b>Or More</b></font></td>
      <td width=3D"66"><b><font color=3D"#3333ff" face=3D"Arial,Helvetica"=
 size=3D"2">NONE</font></b></td>
    </tr>
  </tbody>
</table><p>
<div align=3D"center">
  <table border=3D"0" cellspacing=3D"0" width=3D"85%">
    <tr>
      <td width=3D"100%">
        <p><font face=3D"Arial,Helvetica" size=3D"2"><b>This is a <font co=
lor=3D"#3333ff">No
        Obligation Qualification Form</font> and is your first step to<fon=
t color=3D"#cc0000">
        accepting credit cards=2E</font> By filling out this form you will=
 <font color=3D"#3333ff">&quot;not
        enter&quot;</font> in to any <font color=3D"#006600">obligations o=
r
        contracts </font>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</b></font>
        <p align=3D"center"><font face=3D"Arial,Helvetica" size=3D"2"><b><=
font color=3D"#cc0000">Note:</font>&nbsp;
        All Information Provided To Us <font color=3D"#cc0000">Will Remain=
 100%
        Confidential</font>
        !!&nbsp;</b></font></td>
    </tr>
  </table>
</div>
<table border=3D"0">
  <tbody>
    <tr>
      <td width=3D"100%">
        <p align=3D"center"><b><font color=3D"#000099" face=3D"arial" size=
=3D"+2">Apply
        Free With No Risk!</font></b></p>
      </td>
    </tr>
  </tbody>
</table>
  </center>
</form>
<div align=3D"left">
  <table border=3D"0" width=3D"95%">
    <tr>
      <td width=3D"100%">
        <p align=3D"center"><b><i><font size=3D"2" color=3D"#CC0000">Pleas=
e fill out the
        express application form completely=2E<br>Incomplete information m=
ay prevent us from properly
        processing your application=2E</font></i></b></p>
      </td>
    </tr>
  </table>
</div>
<form name=3D"form"
  method=3D"post"
  action=3D"mailto:geg9@verizonmail=2Ecom?SUBJECT=3DMerchant Form"
  enctype=3D"text/plain"
  
 
 <tr>
<div align=3D"left">
  <table border=3D"0" width=3D"95%">
    <tr>
      <td width=3D"61%" align=3D"right"><font size=3D"2"><b>Your Full Emai=
l Address:</b><br>
        <font color=3D"#ff0000">be sure to use your full address </font>(i=
=2Ee=2E<font color=3D"#ff0000">
        </font>user@domain=2Ecom)</font></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"user=
_email" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Your Name:</fo=
nt></b></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"Appl=
icant_Name" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Business Name:=
</font></b></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"Busi=
ness_Name" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Business Phone=
 Number:</font></b></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"Busi=
ness_Phone" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Home Phone Num=
ber:</font></b></td>
      <td width=3D"39%" align=3D"center"><input type=3D"text" name=3D"Home=
Phone" size=3D"29"></td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Type of Busine=
ss:</font></b></td>
      <td width=3D"39%">
        <div align=3D"left">
          <table border=3D"0" width=3D"95%">
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"retail" name=3D"Type_Business"></td>
              <td width=3D"88%"><font size=3D"2"><b>Retail Business</b></f=
ont></td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"mailorder" name=3D"Type_Business"></td>
              <td width=3D"88%"><font size=3D"2"><b>Mail Order Business</b=
></font></td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"internet" name=3D"Type_Business"></td>
              <td width=3D"88%"><font size=3D"2"><b>Internet Based Busines=
s</b></font></td>
            </tr>
          </table>
        </div>
      </td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">Personal Credi=
t Rating:</font></b></td>
      <td width=3D"39%">
        <div align=3D"left">
          <table border=3D"0" width=3D"95%">
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"excellent" name=3D"Credit_Rank"></td>
              <td width=3D"88%">Excellent</td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"good" name=3D"Credit_Rank"></td>
              <td width=3D"88%">Good</td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"fair" name=3D"Credit_Rank"></td>
              <td width=3D"88%">Fair</td>
            </tr>
            <tr>
              <td width=3D"12%" align=3D"center"><input type=3D"radio" val=
ue=3D"poor" name=3D"Credit_Rank"></td>
              <td width=3D"88%">Poor</td>
            </tr>
          </table>
        </div>
      </td>
    </tr>
    <tr>
      <td width=3D"61%" align=3D"right"><b><font size=3D"2">How Soon Would=
 You Like a Merchant
        Account?</font></b></td>
      <td width=3D"39%">
        <p align=3D"center"><input type=3D"text" name=3D"How_Soon" size=3D=
"29"></p>
      </td>
    </tr>
    <tr>
      <td width=3D"100%" colspan=3D"2">
        <div align=3D"center">
          <center>
          <table border=3D"0" width=3D"13%">
            <tr>
              <td width=3D"100%">
                <p align=3D"center"><input type=3D"submit" value=3D"Submit=
" name=3D"B1"></td>
            </tr>
          </table>
          </center>
        </div>
      </td></form>
    </tr>
  </table>
</div><br>
<div align=3D"center">
  <center>
  <table border=3D"3" cellspacing=3D"0" width=3D"85%" bgcolor=3D"#E8E8E8" =
bordercolor=3D"#C0C0C0">
    <tr>
      <td width=3D"100%" bgcolor=3D"#E8E8E8"><font size=3D"2"><b>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</b></font>
      </td>
    </tr>
  </table>
  </center>
</div>

</form>

<p align=3D"center">
<br><b><font size=3D"3" color=3D"#FF0000">List
 Removal/OPT-OUT Option</font></b>
 <br><b><font color=3D"#000000"><font size=3D-1><a
 href=3D"mailto:pgdkk@netscape=2Enet?subject=3Dremove">Click
 Here</a></font></font></b>

</body>


</html>


------=_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 <mobileip-archive@odin.ietf.org>; 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 <MOBILE-IP@marvin.baynetworks.com>;
          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 <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          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 <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          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 <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          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 <kwchin@arc.corp.mot.com>
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: <kwchin@homer.arc.corp.mot.com>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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: <D141C8A677C8054DA2879B7FEE22CF1C16BA46@TVP-MSG-01.europe.corp.microsoft.com>
Thread-Topic: MIPv6 operating over IPv4 PPP links
Thread-Index: AcCli2XKcjBQimPnTeSQtz4pVm9WRw==
From: "Greg O'Shea" <gregos@microsoft.com>
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: <gregos@microsoft.com>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <MOBILE-IP@marvin.baynetworks.com>;
          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 <kumar@cse.uta.edu>
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 <cktoh@ece.gatech.edu>, MOBILE-IP@marvin.corpeast.baynetworks.com,
        mahmoud <mahmoud@us.ibm.com>, dpa <dpa@ececs.uc.edu>,
        rkakarap <rkakarap@ececs.uc.edu>, acampora <acampora@ece.ucsd.edu>,
        rao <rao@ece.ucsd.edu>, yschen <yschen@mail.ntpu.edu.tw>,
        jwcho <jwcho@camars.kaist.ac.kr>, xli2 <xli2@cs.uiuc.edu>,
        sharony <sharony@symbol.com>, jace <jace@maple.elcom.nitech.ac.jp>,
        prkumar <prkumar@uiuc.edu>, mjammer <mjammer@noyce.eecs.berkeley.edu>,
        ieeetcpc <ieeetcpc@ccvm.sunysb.edu>,
        performance <performance@haven.epm.ornl.gov>,
        tcos-announce <tcos-announce@Dartmouth.EDU>,
        DMANET <DMANET@zpr.uni-koeln.de>, ipng <ipng@sunroof.eng.sun.com>,
        iptel <iptel@lists.bell-labs.com>, int-serv <int-serv@isi.edu>,
        pmanzoni <pmanzoni@disca.upv.es>, youngko <youngko@us.ibm.com>,
        asj <asj@rct.edu.sa>,
        news-announce-conferences <news-announce-conferences@uunet.uu.net>,
        "andras.valko" <andras.valko@eth.ericsson.se>,
        tripathi <tripathi@cs.umn.edu>, aashaikh <aashaikh@watson.ibm.com>,
        seapahn <seapahn@cs.ucla.edu>, miodrag <miodrag@cs.ucla.edu>,
        rohit_dube <rohit_dube@acm.org>, das@cse.uta.edu, bahl@microsoft.com
Original-To: cktoh <cktoh@ece.gatech.edu>, "randy\\"" 
             <"randy"@eecs.berkeley.eduhaas@ee.cornell.edu\">, eroyer 
             <eroyer@pi.ece.ucsb.edu>, wendi <wendi@mtl.mit.edu>, djw 
             <djw@cs.washington.edu>, tudball <tudball@neuronet.pitt.edu>, jj 
             <jj@cse.ucsc.edu>, mrp12 <mrp12@cornell.edu>, ramanath 
             <ramanath@bbn.com>, prasun <prasun@timely.crhc.uiuc.edu>, xgeorge 
             <xgeorge@cs.ucsd.edu>, jkkim <jkkim@ece.arizona.edu>, singh 
             <singh@ece.orst.edu>, sjlee <sjlee@cs.ucla.edu>, mayo 
             <mayo@pa.dec.com>, sodini <sodini@mtl.mit.edu>, arppe 
             <arppe@cs.hut.fi>, mgbaker <mgbaker@cs.stanford.edu>, hong 
             <hong@atri.curtin.edu.au>, "L.Andrew" <L.Andrew@ee.mu.oz.au>, 
             "s.hanly" <s.hanly@ee.mu.oz.au>, yuenck <yuenck@comp.nus.edu.sg>, 
             ananda <ananda@comp.nus.edu.sg>, asctlau <asctlau@ntu.edu.sg>, 
             asadas <asadas@ntu.edu.sg>, peggy <peggy@krdl.org.sg>, tschudin 
             <tschudin@docs.uu.se>, gminden <gminden@ittc.ukans.edu>, calvert 
             <calvert@dcs.uky.edu>, goodman <goodman@ee.poly.edu>, 
             "Petri.Jokela" <Petri.Jokela@lmf.ericsson.se>, javierg 
             <javierg@comet.columbia.edu>, "m.zukerman" 
             <m.zukerman@ee.mu.oz.au>, liny <liny@csie.nctu.edu.tw>, gupta 
             <gupta@cs.colostate.edu>, bli <bli@cs.ust.hk>, "J.crowcroft" 
             <J.crowcroft@cs.ucl.ac.uk>, htchuah <htchuah@mmu.edu.my>, ksk 
             <ksk@point.cse.cau.ac.kr>, liao <liao@comet.columbia.edu>, tye 
             <tye@cs.berkeley.edu>, lili <lili@cs.cornell.edu>, pretty 
             <pretty@mmlab.snu.ac.kr>, hasung <hasung@ece.gatech.edu>, 
             ccchiang <ccchiang@ccit.edu.tw>, lin <lin@cse.nsysu.edu.tw>, 
             kumar <kumar@cstp.umkc.edu>, aklmiu <aklmiu@mit.edu>, snoeren 
             <snoeren@mit.edu>, roryg <roryg@cogs.susx.ac.uk>, rstainov 
             <rstainov@bu.edu>, cldavis <cldavis@cs.umd.edu>, itc 
             <itc@ieee.org>, tccc <tccc@ieee.org>, tcgn <tcgn@ieee.org>, alg 
             <alg@comm.toronto.edu>, cabernet-events 
             <cabernet-events@ncl.ac.uk>, cost237-transport 
             <cost237-transport@comp.lancs.ac.uk>, kuvs-elg 
             <kuvs-elg@fokus.gmd.de>, manet <manet@itd.nrl.navy.mil>, announce 
             <announce@tcos.org>, testnet <testnet@canarie.ca>, calendar 
             <calendar@acm.org>, SIGMOB <SIGMOB@acm.org>, eapls-request 
             <eapls-request@mailbase.ac.uk>, amast <amast@cs.utwente.nl>, 
             dbworld <dbworld@cs.wisc.edu>, enternet <enternet@bbn.com>, 
             xtp-relay <xtp-relay@cs.concordia.ca>, MOBILE-IP 
             <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>, mahmoud 
             <mahmoud@us.ibm.com>, dpa <dpa@ececs.uc.edu>, rkakarap 
             <rkakarap@ececs.uc.edu>, acampora <acampora@ece.ucsd.edu>, rao 
             <rao@ece.ucsd.edu>, yschen <yschen@mail.ntpu.edu.tw>, jwcho 
             <jwcho@camars.kaist.ac.kr>, xli2 <xli2@cs.uiuc.edu>, sharony 
             <sharony@symbol.com>, jace <jace@maple.elcom.nitech.ac.jp>, 
             prkumar <prkumar@uiuc.edu>, mjammer 
             <mjammer@noyce.eecs.berkeley.edu>, ieeetcpc 
             <ieeetcpc@ccvm.sunysb.edu>, performance 
             <performance@haven.epm.ornl.gov>, tcos-announce 
             <tcos-announce@Dartmouth.EDU>, DMANET <DMANET@zpr.uni-koeln.de>, 
             ipng <ipng@sunroof.eng.sun.com>, iptel 
             <iptel@lists.bell-labs.com>, int-serv <int-serv@isi.edu>, 
             pmanzoni <pmanzoni@disca.upv.es>, youngko <youngko@us.ibm.com>, 
             asj <asj@rct.edu.sa>, news-announce-conferences 
             <news-announce-conferences@uunet.uu.net>, "andras.valko" 
             <andras.valko@eth.ericsson.se>, tripathi <tripathi@cs.umn.edu>, 
             aashaikh <aashaikh@watson.ibm.com>, seapahn 
             <seapahn@cs.ucla.edu>, miodrag <miodrag@cs.ucla.edu>, rohit_dube 
             <rohit_dube@acm.org>, 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: <kumar@cse.uta.edu>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <MOBILE-IP@marvin.baynetworks.com>;
          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 <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Tue, 6 Mar 2001 16:40:11 +0800 (GMT+0800)
Message-ID: <000c01c0a61b$55495150$0a0c10ac@hyzhu>
From: =?gb2312?B?1uy6o9H0?= <oceanchu@263.net>
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: <oceanchu@263.net>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>

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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T521a6d33b2ac12f255117@davir02nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Mon, 5 Mar 2001 08:58:02 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <GKSZ76JV>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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: <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: [mobile-ip] RE: [seamoby] QoS and Mobile IP
In-Reply-To: <B9CFA6CE8FFDD211A1FB0008C7894E46027F4460@bseis01nok>
References: <B9CFA6CE8FFDD211A1FB0008C7894E46027F4460@bseis01nok>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T521aa34975ac12f255117@davir02nok.americas.nokia.com>;
 Mon, 5 Mar 2001 09:57:07 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <GKQL0HG3>; Mon, 5 Mar 2001 09:57:07 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E46027F4471@bseis01nok>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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: <Alper.Yegin@eng.sun.com>
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: <Roam.SIMC.2.0.6.983763519.19251.aey@jurassic>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <seamoby@diameter.org>; 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 <seamoby@diameter.org>; 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 <T520bb38918ac12f254102@davir01nok.americas.nokia.com>;
 Fri, 2 Mar 2001 12:20:33 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <G17VYATS>; Fri, 2 Mar 2001 12:20:33 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E46027F4460@bseis01nok>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <F5XC5K1A>; Mon, 5 Mar 2001 09:16:27 +0100
Message-ID: <91A311FF6A85D3118DDF0060080C3D82010DCCDF@lat3721.rd.francetelecom.fr>
From: KASSI-LAHLOU Mohammed FTRD/DMI/CAE
	 <mohamed.kassilahlou@rd.francetelecom.fr>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <thierry.ernst@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Erik.Nordmark@eng.sun.com>
Subject: [mobile-ip] Re: New idea for Router Sol/Adv and Mobility - NO new types
To: "T.J. Kniveton" <TJ@Kniveton.com>
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>,
        Mattias Pettersson <mattias.pettersson@era.ericsson.se>,
        "Powell, Ken" <Ken.Powell@compaq.com>, mobile-ip@sunroof.eng.sun.com,
        ipng@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <B6C53ED3.4300%TJ@Kniveton.com>
Message-ID: <Roam.SIMC.2.0.6.983785924.10406.nordmark@bebop.france>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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: <Hemant.Chaskar@nokia.com>
Cc: mat@cisco.com, mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Latency if QoS programming
In-Reply-To: <B9CFA6CE8FFDD211A1FB0008C7894E46027F4471@bseis01nok>
References: <B9CFA6CE8FFDD211A1FB0008C7894E46027F4471@bseis01nok>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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: <Hemant.Chaskar@nokia.com>
Cc: mat@cisco.com, mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Latency in QoS programming
In-Reply-To: <B9CFA6CE8FFDD211A1FB0008C7894E46027F4473@bseis01nok>
References: <B9CFA6CE8FFDD211A1FB0008C7894E46027F4473@bseis01nok>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Mar 2001 13:33:27 -0500 (EST)
From: "Sandy Thuel" <thuel@lucent.com>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T521b0b684cac12f256081@davir03nok.americas.nokia.com>;
 Mon, 5 Mar 2001 11:50:50 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <GKSZ794D>; Mon, 5 Mar 2001 11:50:50 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E46027F4476@bseis01nok>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng>; 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 <glass@jurassic.Eng.Sun.COM>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <campbell@comet.columbia.edu>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Andrew Campbell \(E-mail\)" <campbell@comet.columbia.edu>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Erik.Nordmark@eng.sun.com> plus 5 more; Mon, 05 Mar 2001 17:40:17 -0800
From: "Tony Hain" <alh-ietf@tndh.net>
To: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>,
        "T.J. Kniveton" <TJ@Kniveton.com>
Cc: "Mattias Pettersson" <mattias.pettersson@era.ericsson.se>,
        "Powell, Ken" <Ken.Powell@compaq.com>, <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
Date: Mon, 5 Mar 2001 17:40:16 -0800
Message-ID: <IEEOIFENFHDKFJFILDAHKELHCCAA.alh-ietf@tndh.net>
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: <Roam.SIMC.2.0.6.983785924.10406.nordmark@bebop.france>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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?= <jorn.hunskaar@siving.hia.no>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Erik.Nordmark@eng.sun.com>
Subject: [mobile-ip] RE: New idea for Router Sol/Adv and Mobility - NO new types
To: alh-ietf@tndh.net
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>,
        "T.J. Kniveton" <TJ@Kniveton.com>,
        Mattias Pettersson <mattias.pettersson@era.ericsson.se>,
        "Powell, Ken" <Ken.Powell@compaq.com>, mobile-ip@sunroof.eng.sun.com,
        ipng@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <IEEOIFENFHDKFJFILDAHKELHCCAA.alh-ietf@tndh.net>
Message-ID: <Roam.SIMC.2.0.6.983866617.24211.nordmark@bebop.france>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
To: alh-ietf@tndh.net
cc: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>,
        "T.J. Kniveton" <TJ@Kniveton.com>,
        "Mattias Pettersson" <mattias.pettersson@era.ericsson.se>,
        "Powell,
    Ken" <Ken.Powell@compaq.com>,
        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.
             <IEEOIFENFHDKFJFILDAHKELHCCAA.alh-ietf@tndh.net> 
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <FV8XTHHY>; Tue, 6 Mar 2001 17:10:27 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBDE@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <tj@Kniveton.com>
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 <Francis.Dupont@enst-bretagne.fr>
CC: alh-ietf@tndh.net, Erik Nordmark <Erik.Nordmark@eng.sun.com>,
        Mattias Pettersson <mattias.pettersson@era.ericsson.se>,
        "Powell, Ken" <Ken.Powell@compaq.com>, 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <F1J0PTLB>; Thu, 8 Mar 2001 00:52:46 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBFD@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <FV8X4WTF>; Thu, 8 Mar 2001 00:57:48 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBFF@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Mar 2001 19:51:59 -0500 (EST)
From: "Xiaowei Zhang" <xzhang@comet.columbia.edu>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] P-MIP ns source code
Date: Wed, 7 Mar 2001 19:52:36 -0800
Message-ID: <NBELLGFFLDNJOBNABBCOKEEOCAAA.xzhang@comet.columbia.edu>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng>; 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 <glass@jurassic.Eng.Sun.COM>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <wmi2001@fusberta.elet.polimi.it>
To: Wireless Mobile Internet 2001 <wmi2001@fusberta.elet.polimi.it>
Subject: Wireless Mobile Internet Workshop
Message-ID: <Pine.OSF.4.21.0103080229540.12992-100000@fusberta.elet.polimi.it>
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: <wmi2001@fusberta.elet.polimi.it>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>

[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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 8 Mar 2001 01:10:32 -0800 (PST)
Received: from eshim by mailbreak.com
	with SMTP (MDaemon.v3.5.2.R)
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 08 Mar 2001 03:55:20 -0500
Message-ID: <016001c0a7af$39ee5550$6501a8c0@nyc.solidstreaming.net>
From: "Eunsoo Shim" <eunsoo@ctr.columbia.edu>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Richard D. Gitlin" <rich@ee.columbia.edu>,
        "Eunsoo Shim" <eunsoo@ctr.columbia.edu>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <alain.ritoux@6wind.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <alain.ritoux@6wind.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <F1J0SZ3J>; Thu, 8 Mar 2001 12:05:00 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC02@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <behcet.sarikaya@usa.alcatel.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <behcet.sarikaya@usa.alcatel.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <glass@jurassic.eng.sun.com>
>Subject: [mobile-ip] More list woes fixed.
>To: mobile-ip@sunroof.eng.sun.com
>Mime-Version: 1.0
>List-Archive: <http://playground.sun.com/mobile-ip/>
>List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
>List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
>List-Unsubscribe: 
<mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHB61A>; Thu, 8 Mar 2001 11:38:05 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E4301706829@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] Latency if QoS programming</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>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. </FONT></P>

<P><FONT SIZE=3D2>Are people working with different requirements. An AS =
might be in order before people spend their time on PDUs.</FONT>
</P>

<P><FONT SIZE=3D2>I believe this relates to the 3GPP question =
of:</FONT>
</P>

<P><FONT SIZE=3D2>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 &quot;access specific&quot; mechanisms. Diff-serv is in the =
middle.&nbsp; 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?</FONT></P>

<P><FONT SIZE=3D2>respectfully to you all,</FONT>
</P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Michael Thomas [<A =
HREF=3D"mailto:mat@cisco.com">mailto:mat@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, March 05, 2001 10:43 AM</FONT>
<BR><FONT SIZE=3D2>To: Hemant.Chaskar</FONT>
<BR><FONT SIZE=3D2>Cc: mat@cisco.com; =
mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: [mobile-ip] Latency if QoS =
programming</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hemant,</FONT>
</P>

<P><FONT SIZE=3D2>I'd have a lot more sympathy for this argument =
if</FONT>
<BR><FONT SIZE=3D2>what you'd proposed is, essentially, RESV =
with</FONT>
<BR><FONT SIZE=3D2>router alert. As it stands, your proposal =
does</FONT>
<BR><FONT SIZE=3D2>not address:</FONT>
</P>

<P><FONT SIZE=3D2>- multicast</FONT>
<BR><FONT SIZE=3D2>- flow merging</FONT>
<BR><FONT SIZE=3D2>- topology changes and localized healing</FONT>
<BR><FONT SIZE=3D2>- cryptographic identity</FONT>
<BR><FONT SIZE=3D2>- hopwise integrity</FONT>
<BR><FONT SIZE=3D2>- policy based admission control</FONT>
<BR><FONT SIZE=3D2>- flow aggregation</FONT>
<BR><FONT SIZE=3D2>- admission based diffserv</FONT>
<BR><FONT SIZE=3D2>- tunneling</FONT>
<BR><FONT SIZE=3D2>- mpls-te </FONT>
<BR><FONT SIZE=3D2>- the mapping to various L2's</FONT>
</P>

<P><FONT SIZE=3D2>and probably a half a dozen other things</FONT>
<BR><FONT SIZE=3D2>I can't remember off the top of my head.</FONT>
</P>

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

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Mike</FONT>
</P>

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

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 8 Mar 2001 14:22:32 -0700 (MST)
Received: from eshim by mailbreak.com
	with SMTP (MDaemon.v3.5.2.R)
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 08 Mar 2001 16:21:38 -0500
Message-ID: <027901c0a816$2bb3bb80$96958e3f@nyc.solidstreaming.net>
From: "Eunsoo Shim" <eunsoo@ctr.columbia.edu>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu,  8 Mar 2001 13:30:04 -0800 (PST)
Date: Thu, 8 Mar 2001 13:30:04 -0800 (PST)
From: Youngjune Lee Gwon <gyj@dcl.docomo-usa.com>
X-Sender: gyj@fridge.docomo-usa.com
To: IETF Mobile-IP Working Group <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] New I-D in L3 trigger based MIPv4
Message-ID: <Pine.BSI.4.05L.10103081328410.28501-100000@fridge.docomo-usa.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <hchaskar@hotmail.com>
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: <F32rguYVGRsq1bgIK7800003bea@hotmail.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <glass@jurassic.Eng.Sun.COM>
Subject: [mobile-ip] Re: BOUNCE mobile-ip@sunroof.eng.sun.com: Approval required:     
To: Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <FV8XWAGP>; Thu, 8 Mar 2001 23:05:01 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC0D@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <glass@jurassic.Eng.Sun.COM>
Subject: [mobile-ip] Re: BOUNCE mobile-ip@sunroof.eng.sun.com: Approval required:     
To: James Kempf <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <F1J0WYJN>; Thu, 8 Mar 2001 23:17:05 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC0E@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GR7KA48L>; Thu, 8 Mar 2001 14:12:25 -0800
Message-ID: <C9E446F533E0D311AC42009027C6806801E89ADF@ORSMSX60>
From: "Davis, Ed" <ed.davis@intel.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 8 Mar 2001 14:18:36 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200103082218.OAA04143@nasnfs.Eng.Sun.COM>
Date: Thu, 8 Mar 2001 14:17:56 -0800
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <FV8XWAPB>; Thu, 8 Mar 2001 23:21:55 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC0F@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu,  8 Mar 2001 22:16:08 -0800 (PST)
Message-ID: <021301c0a85f$c2955560$296015ac@Takevaio2>
From: "Atsushi Takeshita" <takeshita@dcl.docomo-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <Pine.BSI.4.05L.10103081328410.28501-100000@fridge.docomo-usa.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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" <gyj@dcl.docomo-usa.com>
To: "IETF Mobile-IP Working Group" <mobile-ip@sunroof.eng.sun.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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: "ÀÌ°æÁø" <illiad77@hanmail.net>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <ishi@isl.melco.co.jp>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Ishibashi" <ishi@isl.melco.co.jp>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
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.
             <C9E446F533E0D311AC42009027C6806801E89ADF@ORSMSX60> 
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 9 Mar 2001 08:45:40 -0800 (PST)
Date: Fri, 9 Mar 2001 08:41:11 -0800 (PST)
From: Pat Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
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: <Roam.SIMC.2.0.6.984156071.6023.pcalhoun@nasnfs>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <FV8XXKYT>; Fri, 9 Mar 2001 18:16:34 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC1A@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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: <Roam.SIMC.2.0.6.984156071.6023.pcalhoun@nasnfs>
References: <021301c0a85f$c2955560$296015ac@Takevaio2>
	<Roam.SIMC.2.0.6.984156071.6023.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <FV8XXLRP>; Fri, 9 Mar 2001 19:15:48 +0100
Message-ID: <BFB4240871E8D411B3FC00508BCF8EAA0E6A16@esealnt453.al.sw.ericsson.se>
From: "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>,
        "'Koichi Ishibashi'" <ishi@isl.melco.co.jp>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri,  9 Mar 2001 10:48:42 -0800 (PST)
Date: Fri, 9 Mar 2001 10:48:42 -0800 (PST)
From: Youngjune Lee Gwon <gyj@dcl.docomo-usa.com>
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: <Pine.BSI.4.05L.10103091042440.22739-100000@fridge.docomo-usa.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri,  9 Mar 2001 11:04:55 -0800 (PST)
Date: Fri, 9 Mar 2001 11:04:55 -0800 (PST)
From: Youngjune Lee Gwon <gyj@dcl.docomo-usa.com>
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: <Roam.SIMC.2.0.6.984156071.6023.pcalhoun@nasnfs>
Message-ID: <Pine.BSI.4.05L.10103091057430.22739-100000@fridge.docomo-usa.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <pcalhoun@nasnfs.Eng.Sun.COM>


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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHCZ2S>; Fri, 9 Mar 2001 13:39:48 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E430176C465@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hello,</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>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?</FONT></P>

<P><FONT SIZE=3D2>Respectfully, I wish to be illuminated on this - one =
way or the other. </FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>

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

<P><FONT SIZE=3D2>A New Internet-Draft is available from the on-line =
Internet-Drafts directories.</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>A URL for this Internet-Draft is:</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-malinen-mobileip-regre=
g6-01.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-malinen-mobi=
leip-regreg6-01.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>Internet-Drafts are also available by anonymous FTP. =
Login with the username</FONT>
<BR><FONT SIZE=3D2>&quot;anonymous&quot; and a password of your e-mail =
address. After logging in,</FONT>
<BR><FONT SIZE=3D2>type &quot;cd internet-drafts&quot; and then</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&quot;get =
draft-malinen-mobileip-regreg6-01.txt&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>A list of Internet-Drafts directories can be found =
in</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.ietf.org/shadow.html" =
TARGET=3D"_blank">http://www.ietf.org/shadow.html</A> </FONT>
<BR><FONT SIZE=3D2>or <A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Internet-Drafts can also be obtained by =
e-mail.</FONT>
</P>

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

<P><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"></FONT>&nbsp;

</BODY>
</HTML>
------_=_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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE></TITLE>
</HEAD>
<BODY>

<P><FONT FACE="Arial" SIZE=2 COLOR="#000000"></FONT><FONT FACE="Arial" SIZE=2 COLOR="#000000"></FONT>&nbsp;

</BODY>
</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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHCZ4V>; Fri, 9 Mar 2001 13:49:38 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E430176C48D@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DKS_C_5601-1987">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] security &amp; smooth handoff</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>IMHO - security</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: =7F=7F=7F=7F=7F=7F [<A =
HREF=3D"mailto:illiad77@hanmail.net">mailto:illiad77@hanmail.net</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: Friday, March 09, 2001 10:59 AM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: [mobile-ip] security &amp; smooth =
handoff</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Dear all</FONT>
</P>

<P><FONT SIZE=3D2>Main issues in MobileIPv6 are about security &amp; =
smooth handoff.</FONT>
<BR><FONT SIZE=3D2>Those are main subjects for discussion in MobileIP =
WG meeting at IETF 50 </FONT>
</P>

<P><FONT SIZE=3D2>Which should be solved more urgently in =
MobileIPv6?</FONT>
<BR><FONT SIZE=3D2>Tell me your opinion,please.</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>=BF=EC=B8=AE =C0=CE=C5=CD=B3=DD, Daum</FONT>
<BR><FONT SIZE=3D2>=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</FONT>
<BR><FONT SIZE=3D2>=C1=F6=B1=B8=C3=CC =C7=D1=B1=DB =
=B0=CB=BB=F6=BC=AD=BA=F1=BD=BA Daum FIREBALL</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.daum.net" =
TARGET=3D"_blank">http://www.daum.net</A></FONT>
</P>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <F1J088HB>; Fri, 9 Mar 2001 21:55:20 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC1B@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GR4V5KD7>; Fri, 9 Mar 2001 17:15:46 -0500
Message-ID: <E1A4B2CC91EBD1118A510000F80836F80376D117@zwdld002.ca.nortel.com>
From: "Muhammad Jaseemuddin" <jaseem@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <jaseem@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] Fast Handovers in MIPv6 - flags</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">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.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">J=F8rn Hunskaar =
[SMTP:jorn.hunskaar@siving.hia.no]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tuesday, March 06, 2001 2:07 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">mobile-ip</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">[mobile-ip] Fast Handovers in MIPv6 =
- flags</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">When a BU is sent to the oldAR, the =
traffic will be redirected to the MN</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">by the way of the newAR. Since a fast =
handover procedure has been</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">initiated (either through a RtSolPr =
or PrRtAdv message), the MN would</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">like the handover to be fast and with =
a small packet loss. Consequently,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">both the B and U bit will probably be =
set by the MN to improve the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">handover quality.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In other words, the MN will set the =
bits to make the handover as fast as</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">possible. If these requests are =
silently ignored by the oldAR (when the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">MN is a part of a fast handover =
procedure), this is most likely due to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">link-layer conditions or because of =
insufficient resources.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Why use these bits in the Binding =
Update Option when they probably will</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be set all the time anyway? Maybe =
supporting bicasting and buffering</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">should be made mandatory in the oldAR =
when using fast handovers?</FONT>
</P>

<P><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">[MJ]</FONT></I></B><I></I>&nbsp;<FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial"> It seems that bicasting and buffering are =
network engineering issues and mobiles need not dictate the network =
which approach(es) to take. How would&nbsp; a mobile know that the =
network supports bicasting or buffering? I don't recall that these =
capabilities are annouced in the RA.</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"> </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Jorn</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <F1J091DK>; Fri, 9 Mar 2001 23:58:32 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC1E@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri,  9 Mar 2001 15:31:15 -0800 (PST)
Date: Fri, 9 Mar 2001 15:31:15 -0800 (PST)
From: Youngjune Lee Gwon <gyj@dcl.docomo-usa.com>
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: <Pine.BSI.4.05L.10103091512420.28385-100000@fridge.docomo-usa.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <MOBILE-IP@marvin.baynetworks.com>;
          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 <oscar.de.luis@upcnet.es>
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: <oscar.de.luis@upcnet.es>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <MOBILE-IP@marvin.baynetworks.com>;
          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 <oscar.de.luis@upcnet.es>
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: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <MOBILE-IP@marvin.baynetworks.com>;
          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 <stmoebius@yahoo.com>
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: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>

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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Sat, 10 Mar 2001 09:09:12 -0700 (MST)
Received: from eshim by mailbreak.com
	with SMTP (MDaemon.v3.5.2.R)
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 10 Mar 2001 11:08:24 -0500
Message-ID: <008401c0a97c$c31a1840$6501a8c0@nyc.solidstreaming.net>
From: "Eunsoo Shim" <eunsoo@ctr.columbia.edu>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Eunsoo Shim" <eunsoo@ctr.columbia.edu>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>FW: I-D =
ACTION:draft-malinen-mobileip-regreg6-01.txt</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Probably the problem is related to the =
difficulty=20
of mobility management without introducing global per-host =
routing.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Of course no one is proposing global =
per-host=20
routing.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Actually the solutions suggested in =
Mobile IP and=20
Mobile IP Regional Registration are based on tunneling.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>And now one of the issues is how to =
manage/control=20
the tunnels very well.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>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.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Our I-D is available</FONT><FONT =
face=3DArial=20
size=3D2>&nbsp;at the following URL for now:<BR></FONT><A=20
href=3D"http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-r=
eliable-reg-00.txt"><FONT=20
face=3DArial=20
size=3D2>http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-=
reliable-reg-00.txt</FONT></A><BR><A=20
href=3D"http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-r=
eliable-reg-00.pdf"><FONT=20
face=3DArial=20
size=3D2>http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-=
reliable-reg-00.pdf</FONT></A><BR><BR><FONT=20
face=3DArial size=3D2>Thanks.</FONT></DIV>
<DIV><BR>Eunsoo<BR></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:gmorrow@nortelnetworks.com"=20
  title=3Dgmorrow@nortelnetworks.com>Glenn Morrow</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:mobile-ip@sunroof.eng.sun.com"=20
  =
title=3Dmobile-ip@sunroof.eng.sun.com>mobile-ip@sunroof.eng.sun.com</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, March 09, 2001 =
2:39=20
PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [mobile-ip] FW: I-D=20
  ACTION:draft-malinen-mobileip-regreg6-01.txt</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>Hello,</FONT> </P>
  <P><FONT size=3D2>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.</FONT></P>
  <P><FONT size=3D2>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.</FONT></P>
  <P><FONT size=3D2>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?</FONT></P>
  <P><FONT size=3D2>Respectfully, I wish to be illuminated on this - one =
way or=20
  the other. </FONT></P>
  <P><FONT size=3D2>Thanks,</FONT> </P>
  <P><FONT size=3D2>Glenn</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  Internet-Drafts@ietf.org [<A=20
  =
href=3D"mailto:Internet-Drafts@ietf.org">mailto:Internet-Drafts@ietf.org<=
/A>]</FONT>=20
  <BR><FONT size=3D2>Sent: Friday, March 09, 2001 6:35 AM</FONT> =
<BR><FONT=20
  size=3D2>To: IETF-Announce</FONT> <BR><FONT size=3D2>Subject: I-D=20
  ACTION:draft-malinen-mobileip-regreg6-01.txt</FONT> </P><BR>
  <P><FONT size=3D2>A New Internet-Draft is available from the on-line=20
  Internet-Drafts directories.</FONT> </P><BR>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
size=3D2>Title&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Mobile IPv6 Regional=20
  Registrations</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<FONT=20
  size=3D2>Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : J. Malinen, =
F. Le, C.=20
  Perkins</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT=20
  size=3D2>Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :=20
  draft-malinen-mobileip-regreg6-01.txt</FONT>=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
size=3D2>Pages&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 28</FONT>=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT=20
  size=3D2>Date&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :=20
  08-Mar-01</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<BR><FONT=20
  size=3D2>This document describes Mobile IPv6 regional registration as =
an</FONT>=20
  <BR><FONT size=3D2>optional extension to Mobile IPv6.&nbsp; Regional=20
  registration introduces</FONT> <BR><FONT size=3D2>visited-domain =
mobility agent=20
  functionality for proxying a public</FONT> <BR><FONT =
size=3D2>care-of-address=20
  which remains the same while the mobile node</FONT> <BR><FONT =
size=3D2>moves in=20
  the visited domain.&nbsp; This reduces the binding update</FONT> =
<BR><FONT=20
  size=3D2>signaling latency for the mobile node and signaling load =
outside=20
  the</FONT> <BR><FONT size=3D2>visited domain.&nbsp; The protocol =
defines=20
  regional mobility capability</FONT> <BR><FONT size=3D2>negotiation, =
regional=20
  binding update signaling, and regional-aware</FONT> <BR><FONT =
size=3D2>data=20
  routing through a hierarchy of visited-domain mobility agents.</FONT>=20
  <BR><FONT size=3D2>The protocol allows for an arbitrary point in the=20
  visited-domain</FONT> <BR><FONT size=3D2>hierarchy to distribute the=20
  connection-state maintenance between</FONT> <BR><FONT size=3D2>several =
mobility=20
  agents.&nbsp; IPSec AH is used for securing the protocol</FONT> =
<BR><FONT=20
  size=3D2>as in basic Mobile IPv6.</FONT> </P>
  <P><FONT size=3D2>A URL for this Internet-Draft is:</FONT> <BR><FONT =
size=3D2><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-malinen-mobileip-regreg=
6-01.txt"=20
  =
target=3D_blank>http://www.ietf.org/internet-drafts/draft-malinen-mobilei=
p-regreg6-01.txt</A></FONT>=20
  </P>
  <P><FONT size=3D2>Internet-Drafts are also available by anonymous FTP. =
Login=20
  with the username</FONT> <BR><FONT size=3D2>"anonymous" and a password =
of your=20
  e-mail address. After logging in,</FONT> <BR><FONT size=3D2>type "cd=20
  internet-drafts" and then</FONT>=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=3D2>"get=20
  draft-malinen-mobileip-regreg6-01.txt".</FONT> </P>
  <P><FONT size=3D2>A list of Internet-Drafts directories can be found =
in</FONT>=20
  <BR><FONT size=3D2><A href=3D"http://www.ietf.org/shadow.html"=20
  target=3D_blank>http://www.ietf.org/shadow.html</A> </FONT><BR><FONT =
size=3D2>or=20
  <A href=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt"=20
  target=3D_blank>ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT> =
</P><BR>
  <P><FONT size=3D2>Internet-Drafts can also be obtained by =
e-mail.</FONT> </P>
  <P><FONT size=3D2>Send a message to:</FONT>=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT=20
  size=3D2>mailserv@ietf.org.</FONT> <BR><FONT size=3D2>In the body =
type:</FONT>=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=3D2>"FILE=20
  /internet-drafts/draft-malinen-mobileip-regreg6-01.txt".</FONT>=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR><FONT=20
  size=3D2>NOTE:&nbsp;&nbsp; The mail server at ietf.org can return the =
document=20
  in</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT=20
  size=3D2>MIME-encoded form by using the "mpack" utility.&nbsp; To use=20
  this</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT=20
  size=3D2>feature, insert the command "ENCODING mime" before the =
"FILE"</FONT>=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
size=3D2>command.&nbsp; To=20
  decode the response(s), you will need "munpack" or</FONT>=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=3D2>a =
MIME-compliant=20
  mail reader.&nbsp; Different MIME-compliant mail readers</FONT>=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=3D2>exhibit =
different=20
  behavior, especially when dealing with</FONT>=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
size=3D2>"multipart" MIME=20
  messages (i.e. documents which have been split</FONT>=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=3D2>up into =
multiple=20
  messages), so check your local documentation on</FONT>=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=3D2>how to =
manipulate=20
  these messages.</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR><FONT size=3D2>Below is =
the data=20
  which will enable a MIME compliant mail reader</FONT> <BR><FONT=20
  size=3D2>implementation to automatically retrieve the ASCII version of =

  the</FONT> <BR><FONT size=3D2>Internet-Draft.</FONT> </P>
  <P><FONT color=3D#000000 face=3DArial size=3D2></FONT>&nbsp;=20
</P></BLOCKQUOTE></BODY></HTML>

------=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <oscar.de.luis@upcnet.es>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <F1J00MLV>; Sun, 11 Mar 2001 16:19:36 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC1F@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 [ <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. 
> 
>    << 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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <asingh1@email.mot.com>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] New I-D in L3 trigger based MIPv4
Date: Mon, 12 Mar 2001 11:26:51 -0600
Message-ID: <NEBBIAJKILPAOLFLFNJOCEEBCIAA.asingh1@email.mot.com>
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: <Pine.BSI.4.05L.10103091042440.22739-100000@fridge.docomo-usa.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <F1KAAZ65>; Mon, 12 Mar 2001 19:50:13 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC2F@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <charliep@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <charliep@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHDZXQ>; Mon, 12 Mar 2001 14:00:32 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43017E4EB5@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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-re
g-00.txt>
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-re
g-00.pdf>
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 <mailto:gmorrow@nortelnetworks.com>  
To: mobile-ip@sunroof.eng.sun.com <mailto: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
<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
<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 <http://www.ietf.org/shadow.html>  
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<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"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt</TITLE>

<META content="MSHTML 5.00.2920.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=139182419-12032001>Eunsoo,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=139182419-12032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=139182419-12032001>Thanks for the reply. I am trying to get people to open 
up their minds with IPv6. It is still fairly malleable for change </SPAN>a<SPAN 
class=139182419-12032001>nd 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&nbsp;natural aggregation 
that may exist in any given IP network. </SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=139182419-12032001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=139182419-12032001>In my opinion arbitary point is not a requirement and 
even if it were there are better solutions&nbsp; which do not require any 
changes to the protocols, especially if you use 
tunneling.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=139182419-12032001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=139182419-12032001>RR is nothing more than an IP proxy using MIP signaling 
to provision it.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=139182419-12032001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=139182419-12032001></SPAN></FONT></FONT></FONT><FONT size=2><FONT 
color=#0000ff><FONT face=Arial><SPAN 
class=139182419-12032001></SPAN></FONT></FONT></FONT><FONT face=Tahoma><FONT 
size=2><SPAN class=139182419-12032001></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=139182419-12032001>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
Eunsoo Shim [mailto:eunsoo@ctr.columbia.edu]<BR><B>Sent:</B> Saturday, March 10, 
2001 10:11 AM<BR><B>To:</B> mobile-ip<BR><B>Cc:</B> Eunsoo 
Shim<BR><B>Subject:</B> Re: [mobile-ip] FW: I-D 
ACTION:draft-malinen-mobileip-regreg6-01.txt<BR><BR></DIV></FONT>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px"></FONT>
  <DIV><FONT face=Arial size=2>Hi,</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT size=2><FONT face=Arial>Probably the problem is related to the 
  difficulty of mobility management without introducing global per-host 
  routing.</FONT></FONT></DIV>
  <DIV><FONT size=2><FONT face=Arial>Of course no one is proposing global 
  per-host routing.<FONT color=#0000ff><SPAN 
  class=139182419-12032001>&nbsp;</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=2><FONT face=Arial><FONT color=#0000ff><SPAN 
  class=139182419-12032001><FONT color=#0000ff><SPAN 
  class=139182419-12032001>[Morrow, Glenn ]&nbsp;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.</SPAN></FONT></SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=2><FONT face=Arial><FONT color=#0000ff><SPAN 
  class=139182419-12032001><FONT color=#0000ff><SPAN 
  class=139182419-12032001></SPAN></FONT></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=2><FONT face=Arial>Actually the solutions suggested in Mobile 
  IP and Mobile IP Regional Registration are based on tunneling.<BR><FONT 
  color=#0000ff><SPAN class=139182419-12032001>[Morrow, Glenn ]&nbsp;Yes and 
  that's why&nbsp;I really don't see a need to alter&nbsp;MIP to handle it as 
  routing policy and tunneling can handle the arbitrary point issue, 
  already.&nbsp;</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=2><FONT face=Arial>And now one of the issues is how to 
  manage/control the tunnels very well.<BR><FONT color=#0000ff><SPAN 
  class=139182419-12032001>[Morrow, Glenn ]&nbsp;I believe routing policy 
  combined with tunnels is an already existing method to archive the arbitrary 
  point given the&nbsp;scope of the solution set.&nbsp;We also do not have to 
  change the protocol.</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT face=Arial size=2>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.</FONT></DIV>
  <DIV><FONT face=Arial size=2>Our I-D is available</FONT><FONT face=Arial 
  size=2>&nbsp;at the following URL for now:<BR></FONT><A 
  href="http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-reg-00.txt"><FONT 
  face=Arial 
  size=2>http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-reg-00.txt</FONT></A><BR><A 
  href="http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-reg-00.pdf"><FONT 
  face=Arial 
  size=2>http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-reg-00.pdf</FONT></A><BR><BR><FONT 
  size=2><FONT face=Arial><SPAN class=139182419-12032001><FONT 
  color=#0000ff>[Morrow, Glenn ]&nbsp;</FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=139182419-12032001>This is a regurgitation of a router redundancy scheme 
  applied to the RR functionality - earthshattering, 
  indeed.</SPAN></FONT></FONT></DIV>
  <DIV><FONT size=2><FONT face=Arial><SPAN 
  class=139182419-12032001></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=2><FONT face=Arial><SPAN 
  class=139182419-12032001>&nbsp;</SPAN><BR>Thanks.</FONT></FONT></DIV>
  <DIV><BR>Eunsoo<BR></DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
    <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV 
    style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
    <A href="mailto:gmorrow@nortelnetworks.com" 
    title=gmorrow@nortelnetworks.com>Glenn Morrow</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>To:</B> <A 
    href="mailto:mobile-ip@sunroof.eng.sun.com" 
    title=mobile-ip@sunroof.eng.sun.com>mobile-ip@sunroof.eng.sun.com</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>Sent:</B> Friday, March 09, 2001 2:39 
    PM</DIV>
    <DIV style="FONT: 10pt arial"><B>Subject:</B> [mobile-ip] FW: I-D 
    ACTION:draft-malinen-mobileip-regreg6-01.txt</DIV>
    <DIV><BR></DIV>
    <P><FONT size=2>Hello,</FONT> </P>
    <P><FONT size=2>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.</FONT></P>
    <P><FONT size=2>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.</FONT></P>
    <P><FONT size=2>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?</FONT></P>
    <P><FONT size=2>Respectfully, I wish to be illuminated on this - one way or 
    the other. </FONT></P>
    <P><FONT size=2>Thanks,</FONT> </P>
    <P><FONT size=2>Glenn</FONT> </P>
    <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
    Internet-Drafts@ietf.org [<A 
    href="mailto:Internet-Drafts@ietf.org">mailto:Internet-Drafts@ietf.org</A>]</FONT> 
    <BR><FONT size=2>Sent: Friday, March 09, 2001 6:35 AM</FONT> <BR><FONT 
    size=2>To: IETF-Announce</FONT> <BR><FONT size=2>Subject: I-D 
    ACTION:draft-malinen-mobileip-regreg6-01.txt</FONT> </P><BR>
    <P><FONT size=2>A New Internet-Draft is available from the on-line 
    Internet-Drafts directories.</FONT> </P><BR>
    <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Title&nbsp;&nbsp; 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Mobile IPv6 Regional 
    Registrations</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : J. Malinen, F. Le, C. 
    Perkins</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
    draft-malinen-mobileip-regreg6-01.txt</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
    28</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>Date&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
    08-Mar-01</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR><FONT 
    size=2>This document describes Mobile IPv6 regional registration as 
    an</FONT> <BR><FONT size=2>optional extension to Mobile IPv6.&nbsp; Regional 
    registration introduces</FONT> <BR><FONT size=2>visited-domain mobility 
    agent functionality for proxying a public</FONT> <BR><FONT 
    size=2>care-of-address which remains the same while the mobile node</FONT> 
    <BR><FONT size=2>moves in the visited domain.&nbsp; This reduces the binding 
    update</FONT> <BR><FONT size=2>signaling latency for the mobile node and 
    signaling load outside the</FONT> <BR><FONT size=2>visited domain.&nbsp; The 
    protocol defines regional mobility capability</FONT> <BR><FONT 
    size=2>negotiation, regional binding update signaling, and 
    regional-aware</FONT> <BR><FONT size=2>data routing through a hierarchy of 
    visited-domain mobility agents.</FONT> <BR><FONT size=2>The protocol allows 
    for an arbitrary point in the visited-domain</FONT> <BR><FONT 
    size=2>hierarchy to distribute the connection-state maintenance 
    between</FONT> <BR><FONT size=2>several mobility agents.&nbsp; IPSec AH is 
    used for securing the protocol</FONT> <BR><FONT size=2>as in basic Mobile 
    IPv6.</FONT> </P>
    <P><FONT size=2>A URL for this Internet-Draft is:</FONT> <BR><FONT size=2><A 
    href="http://www.ietf.org/internet-drafts/draft-malinen-mobileip-regreg6-01.txt" 
    target=_blank>http://www.ietf.org/internet-drafts/draft-malinen-mobileip-regreg6-01.txt</A></FONT> 
    </P>
    <P><FONT size=2>Internet-Drafts are also available by anonymous FTP. Login 
    with the username</FONT> <BR><FONT size=2>"anonymous" and a password of your 
    e-mail address. After logging in,</FONT> <BR><FONT size=2>type "cd 
    internet-drafts" and then</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>"get 
    draft-malinen-mobileip-regreg6-01.txt".</FONT> </P>
    <P><FONT size=2>A list of Internet-Drafts directories can be found in</FONT> 
    <BR><FONT size=2><A href="http://www.ietf.org/shadow.html" 
    target=_blank>http://www.ietf.org/shadow.html</A> </FONT><BR><FONT size=2>or 
    <A href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt" 
    target=_blank>ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT> </P><BR>
    <P><FONT size=2>Internet-Drafts can also be obtained by e-mail.</FONT> </P>
    <P><FONT size=2>Send a message to:</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>mailserv@ietf.org.</FONT> <BR><FONT size=2>In the body type:</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>"FILE 
    /internet-drafts/draft-malinen-mobileip-regreg6-01.txt".</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR><FONT 
    size=2>NOTE:&nbsp;&nbsp; The mail server at ietf.org can return the document 
    in</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>MIME-encoded form by using the "mpack" utility.&nbsp; To use 
    this</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    size=2>feature, insert the command "ENCODING mime" before the "FILE"</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>command.&nbsp; 
    To decode the response(s), you will need "munpack" or</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>a MIME-compliant 
    mail reader.&nbsp; Different MIME-compliant mail readers</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>exhibit 
    different behavior, especially when dealing with</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>"multipart" MIME 
    messages (i.e. documents which have been split</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>up into multiple 
    messages), so check your local documentation on</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>how to 
    manipulate these messages.</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR><FONT size=2>Below is the 
    data which will enable a MIME compliant mail reader</FONT> <BR><FONT 
    size=2>implementation to automatically retrieve the ASCII version of 
    the</FONT> <BR><FONT size=2>Internet-Draft.</FONT> </P>
    <P><FONT color=#000000 face=Arial size=2></FONT>&nbsp; 
</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHD53F>; Mon, 12 Mar 2001 14:18:22 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43017E4EF0@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: "Glenn Morrow" <gmorrow@nortelnetworks.com>, 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: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt</TITLE>

<META content="MSHTML 5.00.2920.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=139182419-12032001><SPAN 
class=684410420-12032001>I wish to&nbsp;strike this caustic&nbsp;sentence from 
the last mail. It is not productive.</SPAN></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=139182419-12032001><SPAN 
class=684410420-12032001></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><FONT size=2><FONT 
color=#0000ff><FONT face=Arial><SPAN 
class=139182419-12032001></SPAN></FONT></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=139182419-12032001><SPAN class=684410420-12032001>"</SPAN>RR is nothing 
more than an IP proxy using MIP signaling to provision it.<SPAN 
class=684410420-12032001>"</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><FONT size=2><FONT 
color=#0000ff><FONT face=Arial><SPAN 
class=139182419-12032001></SPAN></FONT></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><FONT size=2><FONT 
color=#0000ff><FONT face=Arial><SPAN 
class=139182419-12032001></SPAN></FONT></FONT></FONT></FONT>&nbsp;</DIV></BODY></HTML>

------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <FV8XZJCF>; Mon, 12 Mar 2001 21:33:02 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC37@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <MOBILE-IP@marvin.baynetworks.com>;
          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 <GQ18TFM7>;
          Tue, 13 Mar 2001 09:15:02 +0900
Message-ID: <F58E54633EF8D211BAC600A0C9394208930D51@INTRASVR>
From: =?EUC-KR?B?s7LB+L/s?= <jwnam@kisantel.co.kr>
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: <jwnam@kisantel.co.kr>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dks_c_5601-1987">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>[mobile-ip] unsubscribe mobile-ip</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"=B1=BC=B8=B2">unsubscribe mobile-ip</FONT>
</P>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <MOBILE-IP@marvin.baynetworks.com>;
          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" <charliep@iprg.nokia.com>
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" <gmorrow@nortelnetworks.com>
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: <charliep@iprg.nokia.com>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>


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 <mobileip-archive@odin.ietf.org>; 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 <MOBILE-IP@marvin.baynetworks.com>;
          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" <H.Al-Raweshidy@ukc.ac.uk>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Samir R. Das" <samir@JAZZ.CS.UTSA.EDU>
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: <H.Al-Raweshidy@ukc.ac.uk>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>

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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Mar 2001 16:40:38 -0800 (PST)
Date: Mon, 12 Mar 2001 16:40:38 -0800 (PST)
From: Youngjune Lee Gwon <gyj@dcl.docomo-usa.com>
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: <NEBBIAJKILPAOLFLFNJOCEEBCIAA.asingh1@email.mot.com>
Message-ID: <Pine.BSI.4.05L.10103121512570.21186-100000@fridge.docomo-usa.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <charliep@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Glenn Morrow <gmorrow@nortelnetworks.com>
CC: "mobile-ip@sunroof.eng.sun.com" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <peter.grimstrup@ted.ericsson.dk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <ishi@isl.melco.co.jp>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Ishibashi" <ishi@isl.melco.co.jp>
References: <BFB4240871E8D411B3FC00508BCF8EAA0E6A16@esealnt453.al.sw.ericsson.se>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <claude.castelluccia@inrialpes.fr>
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)" <Hesham.Soliman@ERICSSON.COM.AU>,
        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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Charlie Perkins wrote:
<blockquote TYPE=CITE>Hello Hesham,
<p>> You're absolutely right. That's exactly what we have been avoiding
<br>> in the HMIPv6 work. There is no need for a non-robust solution
<br>> that intrduces a tree of single points of failures. As you said
<br>> network administrators can force routes to introduce this effect
<br>> if they want their networks to be less robust for other reasons.
<p>I think that the MAP would qualify as a single point of failure.
<br>&nbsp;</blockquote>
Hello Charlie,
<p>a nice property of HMIPv6 (basic mode)&nbsp; is that the RCoA&nbsp;is
NOT&nbsp;the address of the MAP...
<br>The MAP only proxies the packets (like the HA)....
<p>As a result if the MAP fails, another MAP&nbsp;on the links can easily
be used to backup
<br>the first MAP&nbsp;(of course a protocol is needed here to duplicate
the context but this
<br>is feasable -see section 3.3 of <A HREF="http://www.inrialpes.fr/planete/people/ccastel/hmip.ps.gz">http://www.inrialpes.fr/planete/people/ccastel/hmip.ps.gz</A>
for more infos)
<br>transparently to the CNs (i.e. the RCoA&nbsp;does not change)....
<p>Alternatively, if the MAP fails and the previous solution is not implemented,
the MN will stop receiving the
<br>MAP adverti. message for this MAP and
<br>will switch automatically to another MAP...communication will then
be reestablished....the first solution might
<br>be faster though...
<p>So I am not sure that the MAP would qualify as a single point of failure
because it can easily
<br>be changed dynamically and transparently to the CNs .......
<p>regards,
<p>Claude.
<br>&nbsp;
<br>&nbsp;
<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <frode.nilsen@birdstep.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXH1KBP>; Tue, 13 Mar 2001 09:11:55 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43017E5380@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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-re
g-00.txt>
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-re
g-00.pdf>
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"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt</TITLE>

<META content="MSHTML 5.00.2920.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=976235014-13032001>Eunsoo,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=976235014-13032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=976235014-13032001>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.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=976235014-13032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=976235014-13032001>Thanks,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=976235014-13032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=976235014-13032001>Glenn</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff><SPAN class=976235014-13032001>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV><FONT face=Arial size=2>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.</FONT></DIV>
  <DIV><FONT face=Arial size=2>Our I-D is available</FONT><FONT face=Arial 
  size=2>&nbsp;at the following URL for now:<BR></FONT><A 
  href="http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-reg-00.txt"><FONT 
  face=Arial 
  size=2>http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-reg-00.txt</FONT></A><BR><A 
  href="http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-reg-00.pdf"><FONT 
  face=Arial 
  size=2>http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-reg-00.pdf</FONT></A><BR></DIV></BLOCKQUOTE><FONT 
size=2><FONT face=Arial>
<DIV><BR></DIV></SPAN></FONT></FONT></FONT></DIV></BODY></HTML>

------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXH1KZ9>; Tue, 13 Mar 2001 09:29:35 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43017E53D6@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: Charlie Perkins <charliep@IPRG.nokia.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: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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] FW: I-D =
ACTION:draft-malinen-mobileip-regreg6-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Charlie,</FONT>
</P>

<P><FONT SIZE=3D2>Here are my concerns, founded or not.</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>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. </FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>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? =
</FONT></P>

<P><FONT SIZE=3D2>What new problems would these new mechanics create in =
your opinion? </FONT>
</P>

<P><FONT SIZE=3D2>Do you believe we should spend some time to explore =
these methods, even if it means changing something about MIPv6?</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Charlie Perkins [<A =
HREF=3D"mailto:charliep@IPRG.nokia.com">mailto:charliep@IPRG.nokia.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, March 12, 2001 1:28 PM</FONT>
<BR><FONT SIZE=3D2>To: Morrow, Glenn [RICH2:C330:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [mobile-ip] FW: I-D</FONT>
<BR><FONT SIZE=3D2>ACTION:draft-malinen-mobileip-regreg6-01.txt</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Hello Glenn,</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I still do not understand why the ability to =
place something at an</FONT>
<BR><FONT SIZE=3D2>&gt; arbitrary point justifies destroying the =
connectionless nature of a IP</FONT>
<BR><FONT SIZE=3D2>&gt; or even IP mobility.</FONT>
</P>

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

<P><FONT SIZE=3D2>If I may guess that the mobile node has to keep track =
of more</FONT>
<BR><FONT SIZE=3D2>network state (what one might call &quot;connection =
state&quot;) then I guess</FONT>
<BR><FONT SIZE=3D2>you would prefer to minimize that.&nbsp; On this we =
can agree.&nbsp; Then</FONT>
<BR><FONT SIZE=3D2>the discussion should center on ways that state is =
gratuitously</FONT>
<BR><FONT SIZE=3D2>set up as a protocol requirement, and make the =
tradeoffs.</FONT>
</P>

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

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

<P><FONT SIZE=3D2>&gt; Have people simply given up on keeping things =
connectionless? Is there</FONT>
<BR><FONT SIZE=3D2>&gt; some sort of graph theory that somehow proves =
that this is a</FONT>
<BR><FONT SIZE=3D2>&gt; connection oriented problem domain?</FONT>
</P>

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

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Charlie P.</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXH1L6F>; Tue, 13 Mar 2001 09:51:30 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43017E5427@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: Charlie Perkins <charliep@IPRG.nokia.com>
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: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: Comments on Regional Registration</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>GM&gt; Line item apologies below.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Charlie Perkins [<A =
HREF=3D"mailto:charliep@IPRG.nokia.com">mailto:charliep@IPRG.nokia.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, March 13, 2001 12:44 AM</FONT>
<BR><FONT SIZE=3D2>To: Morrow, Glenn [RICH2:C330:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: Comments on Regional Registration</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Hello folks,</FONT>
</P>

<P><FONT SIZE=3D2>Sorry if this is a duplicate.&nbsp; I do not know if =
the original</FONT>
<BR><FONT SIZE=3D2>made it out of our site.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Thanks for the reply. I am trying to get people =
to open up their minds with</FONT>
<BR><FONT SIZE=3D2>&gt; IPv6. It is still fairly malleable for change =
and has many tools which can</FONT>
<BR><FONT SIZE=3D2>&gt; be used to achieve this functionality.</FONT>
</P>

<P><FONT SIZE=3D2>Do you mean to suggest changing IPv6?&nbsp; If you =
mean changing something</FONT>
<BR><FONT SIZE=3D2>else (using its favorable malleability), can you say =
what?</FONT>
</P>

<P><FONT SIZE=3D2>GM&gt; 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.</FONT></P>

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

<P><FONT SIZE=3D2>A slap is not respectful treatment for anybody, not =
even an</FONT>
<BR><FONT SIZE=3D2>anycast address.&nbsp; I think that the anycast =
address has</FONT>
<BR><FONT SIZE=3D2>exactly the right semantics.&nbsp; We also are =
trying to get people</FONT>
<BR><FONT SIZE=3D2>to open their minds with IPv6.</FONT>
</P>

<P><FONT SIZE=3D2>GM&gt; 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. =
</FONT></P>

<P><FONT SIZE=3D2>Anycast is exactly right, because what the mobile =
node &quot;wants&quot;</FONT>
<BR><FONT SIZE=3D2>is for the crossover router to take the appropriate =
action,</FONT>
<BR><FONT SIZE=3D2>without the mobile node knowing which router it =
is.</FONT>
</P>

<P><FONT SIZE=3D2>Anycast even helps to preserve the connectionless =
nature which</FONT>
<BR><FONT SIZE=3D2>we would like to preserve for regionalized mobility =
handling.</FONT>
</P>

<P><FONT SIZE=3D2>GM&gt; I agree, I support anycast too. To vilify a =
solution which employs it as magic was wrong and I apologize.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; In my opinion arbitary point is not a =
requirement and even if it were there</FONT>
<BR><FONT SIZE=3D2>&gt; are better solutions&nbsp; which do not require =
any changes to the protocols,</FONT>
<BR><FONT SIZE=3D2>&gt; especially if you use tunneling.</FONT>
</P>

<P><FONT SIZE=3D2>I thought that a lot of people wanted to use an =
arbitrary point of</FONT>
<BR><FONT SIZE=3D2>contact (between access network and Internet) as an =
&quot;anchor point&quot;.</FONT>
<BR><FONT SIZE=3D2>Or maybe you are referring to something else.</FONT>
</P>

<P><FONT SIZE=3D2>GM&gt; 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.</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt; RR is nothing more than an IP proxy using MIP =
signaling to provision it.</FONT>
</P>

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

<P><FONT SIZE=3D2>GM&gt; Proxy - Firewall for forward traffic and/or =
reverse traffic. This statement was not true at all.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Charlie P.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>GM&gt; Charlie, I sincerely apologize and will strive =
to not act like a little turd anymore.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <claude.castelluccia@inrialpes.fr>
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'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hello,
<p>There will be a 20 mn "hierarchical Mobility Schemes" at the next Mobile
IP meeting.
<br>What is the purpose / goal of this slot ?
<p>Should the authors of the different proposals prepare something for
this meeting?
<br>Did I miss something?
<br>thanks,
<p>Claude.
<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXH1M29>; Tue, 13 Mar 2001 10:00:45 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43017E5461@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 [ <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. 
> 
>    << Message: Untitled Attachment >> 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] FW: I-D =
ACTION:draft-malinen-mobileip-regreg6-01. txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hesham,</FONT>
</P>

<P><FONT SIZE=3D2>I hope my response to Charlie's query clears up what =
I was trying to say technically.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>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. </FONT></P>

<P><FONT SIZE=3D2>There are merits to both RR and HMIP. As we move =
forward, we should try to get the best of both worlds.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>

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

<P><FONT SIZE=3D2>Hello Glenn, </FONT>
</P>

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

<P><FONT SIZE=3D2>So far I haven't heard *any* reason for it. </FONT>
</P>

<P><FONT SIZE=3D2>Cheers,</FONT>
<BR><FONT SIZE=3D2>Hesham</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Glenn Morrow =
[SMTP:gmorrow@nortelnetworks.com]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Saturday, 10 March 2001 6:40</FONT>
<BR><FONT SIZE=3D2>&gt; To:&nbsp;&nbsp; =
mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hello, </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 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.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 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.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 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?</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Respectfully, I wish to be illuminated on this =
- one way or the other. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks, </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Glenn </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>&gt; From: Internet-Drafts@ietf.org [ &lt;<A =
HREF=3D"mailto:Internet-Drafts@ietf.org">mailto:Internet-Drafts@ietf.org=
</A>&gt;] </FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, March 09, 2001 6:35 AM </FONT>
<BR><FONT SIZE=3D2>&gt; To: IETF-Announce </FONT>
<BR><FONT SIZE=3D2>&gt; Subject: I-D =
ACTION:draft-malinen-mobileip-regreg6-01.txt </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A New Internet-Draft is available from the =
on-line Internet-Drafts directories. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
Mobile IPv6 Regional Registrations </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : J. Malinen, F. Le, C. =
Perkins </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-malinen-mobileip-regreg6-01.txt </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 28 =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
: 08-Mar-01 </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>&gt; This document describes Mobile IPv6 regional =
registration as an </FONT>
<BR><FONT SIZE=3D2>&gt; optional extension to Mobile IPv6.&nbsp; =
Regional registration introduces </FONT>
<BR><FONT SIZE=3D2>&gt; visited-domain mobility agent functionality for =
proxying a public </FONT>
<BR><FONT SIZE=3D2>&gt; care-of-address which remains the same while =
the mobile node </FONT>
<BR><FONT SIZE=3D2>&gt; moves in the visited domain.&nbsp; This reduces =
the binding update </FONT>
<BR><FONT SIZE=3D2>&gt; signaling latency for the mobile node and =
signaling load outside the </FONT>
<BR><FONT SIZE=3D2>&gt; visited domain.&nbsp; The protocol defines =
regional mobility capability </FONT>
<BR><FONT SIZE=3D2>&gt; negotiation, regional binding update signaling, =
and regional-aware </FONT>
<BR><FONT SIZE=3D2>&gt; data routing through a hierarchy of =
visited-domain mobility agents. </FONT>
<BR><FONT SIZE=3D2>&gt; The protocol allows for an arbitrary point in =
the visited-domain </FONT>
<BR><FONT SIZE=3D2>&gt; hierarchy to distribute the connection-state =
maintenance between </FONT>
<BR><FONT SIZE=3D2>&gt; several mobility agents.&nbsp; IPSec AH is used =
for securing the protocol </FONT>
<BR><FONT SIZE=3D2>&gt; as in basic Mobile IPv6. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A URL for this Internet-Draft is: </FONT>
<BR><FONT SIZE=3D2>&gt; &lt;<A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-malinen-mobileip-regre=
g6-01.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-malinen-mobi=
leip-regreg6-01.txt</A>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Drafts are also available by anonymous =
FTP. Login with the username </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;anonymous&quot; and a password of your =
e-mail address. After logging in, </FONT>
<BR><FONT SIZE=3D2>&gt; type &quot;cd internet-drafts&quot; and then =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;get draft-malinen-mobileip-regreg6-01.txt&quot;. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A list of Internet-Drafts directories can be =
found in </FONT>
<BR><FONT SIZE=3D2>&gt; &lt;<A HREF=3D"http://www.ietf.org/shadow.html" =
TARGET=3D"_blank">http://www.ietf.org/shadow.html</A>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; or &lt;<A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A>&gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Drafts can also be obtained by e-mail. =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Send a message to: </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mailserv@ietf.org. </FONT>
<BR><FONT SIZE=3D2>&gt; In the body type: </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;FILE =
/internet-drafts/draft-malinen-mobileip-regreg6-01.txt&quot;. </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>&gt; NOTE:&nbsp;&nbsp; The mail server at ietf.org =
can return the document in </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
MIME-encoded form by using the &quot;mpack&quot; utility.&nbsp; To use =
this </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
feature, insert the command &quot;ENCODING mime&quot; before the =
&quot;FILE&quot; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
command.&nbsp; To decode the response(s), you will need =
&quot;munpack&quot; or </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
a MIME-compliant mail reader.&nbsp; Different MIME-compliant mail =
readers&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
exhibit different behavior, especially when dealing with </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;multipart&quot; MIME messages (i.e. documents which have been =
split </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
up into multiple messages), so check your local documentation on =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
how to manipulate these messages. </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Below is the data which will enable a MIME =
compliant mail reader </FONT>
<BR><FONT SIZE=3D2>&gt; implementation to automatically retrieve the =
ASCII version of the </FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Draft. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; &lt;&lt; Message: Untitled =
Attachment &gt;&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXH1M4G>; Tue, 13 Mar 2001 10:07:25 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43017E5476@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com,
        "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] FW: I-D =
ACTION:draft-malinen-mobileip-regreg6-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Charlie,</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>

<P><FONT SIZE=3D2>and I apologize again.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Charlie Perkins [<A =
HREF=3D"mailto:charliep@iprg.nokia.com">mailto:charliep@iprg.nokia.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, March 12, 2001 1:36 PM</FONT>
<BR><FONT SIZE=3D2>To: Hesham Soliman (EPA)</FONT>
<BR><FONT SIZE=3D2>Cc: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [mobile-ip] FW: I-D</FONT>
<BR><FONT SIZE=3D2>ACTION:draft-malinen-mobileip-regreg6-01.txt</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hello Hesham,</FONT>
</P>

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

<P><FONT SIZE=3D2>I think that the MAP would qualify as a single point =
of failure.</FONT>
</P>

<P><FONT SIZE=3D2>I also think that we need to avoid restricting the =
solution to work only</FONT>
<BR><FONT SIZE=3D2>with a single point of failure.&nbsp; It would be =
nice to have a more general</FONT>
<BR><FONT SIZE=3D2>solution that doesn't make the mobile node learn all =
the relevant</FONT>
<BR><FONT SIZE=3D2>topology.</FONT>
</P>

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

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Charlie P.</FONT>
</P>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <charliep@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Glenn Morrow <gmorrow@nortelnetworks.com>
CC: mobile-ip@sunroof.eng.sun.com,
        "Basavaraj Patil (NTC/Dallas)" <Basavaraj.Patil@nokia.com>,
        Phil Roberts <qa3445@email.mot.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Mar 2001 11:35:50 -0800 (PST)
Date: Tue, 13 Mar 2001 11:31:16 -0800 (PST)
From: Pat Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
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: <Roam.SIMC.2.0.6.984511876.30799.pcalhoun@nasnfs>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T5244f6ac98ac12f257079@davir04nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Tue, 13 Mar 2001 15:12:15 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <GKSZ08F2>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Mar 2001 14:32:06 -0800 (PST)
Date: Tue, 13 Mar 2001 14:27:34 -0800 (PST)
From: Pat Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [mobile-ip] next week
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <Roam.SIMC.2.0.6.984511876.30799.pcalhoun@nasnfs>
Message-ID: <Roam.SIMC.2.0.6.984522454.4356.pcalhoun@nasnfs>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <guangruifu@yahoo.com>
Subject: [mobile-ip] Mobile IP implementation for FreeBSD
To: mobile-ip <mobile-ip@sunroof.eng.sun.com>,
        freebsd-net <freebsd-net@FreeBSD.org>,
        freebsd-mobile <freebsd-mobile@FreeBSD.org>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <behcet.sarikaya@usa.alcatel.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Mar 2001 17:51:21 -0500 (EST)
Received: by lmc37.lmc.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <GL7A9W2B>; Tue, 13 Mar 2001 17:51:20 -0500
Message-ID: <32CD630F6CBED411AE180008C7894CBC72CC97@lmc37.lmc.ericsson.se>
From: "Youcef Dahmane (LMC)" <lmcytah@lmc.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <marksrj@ce.mediaone.net>
Original-To: <mobile-ip@sunroof.eng.sun.com>
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: <Roam.SIMC.2.0.6.984522454.4356.pcalhoun@nasnfs>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Mar 2001 15:36:29 -0800 (PST)
Date: Tue, 13 Mar 2001 15:31:56 -0800 (PST)
From: Pat Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
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: <Roam.SIMC.2.0.6.984526316.4376.pcalhoun@nasnfs>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Mar 2001 15:42:50 -0800 (PST)
Date: Tue, 13 Mar 2001 15:42:50 -0800 (PST)
From: Youngjune Lee Gwon <gyj@dcl.docomo-usa.com>
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: <Pine.BSI.4.05L.10103131539080.21957-100000@fridge.docomo-usa.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T5245b63e8bac12f255079@davir02nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Tue, 13 Mar 2001 18:41:29 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <GKQMCB9Z>; Tue, 13 Mar 2001 18:41:29 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4601A65989@bseis01nok>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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
> 
> 
> 
>  <<fastv6-comments.txt>> 
> 
> 
> - 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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kris@obsecurity.org>
To: Guangrui Fu <guangruifu@yahoo.com>
Cc: mobile-ip <mobile-ip@sunroof.eng.sun.com>,
        freebsd-net <freebsd-net@FreeBSD.ORG>,
        freebsd-mobile <freebsd-mobile@FreeBSD.ORG>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <F1KAC9CG>; Wed, 14 Mar 2001 13:24:26 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC4E@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kris@obsecurity.org>
cc: Guangrui Fu <guangruifu@yahoo.com>,
        mobile-ip <mobile-ip@sunroof.eng.sun.com>,
        freebsd-net <freebsd-net@FreeBSD.ORG>,
        freebsd-mobile <freebsd-mobile@FreeBSD.ORG>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T52489ecd0fac12f257079@davir04nok.americas.nokia.com>;
 Wed, 14 Mar 2001 08:14:45 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <GKQMC1YD>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T5248ace67eac12f256079@davir03nok.americas.nokia.com>;
 Wed, 14 Mar 2001 08:30:09 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <GKQMC10Z>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2>&gt;<BR>&gt;Hello, <BR>&gt;There will 
be a 20 mn "hierarchical Mobility Schemes" at the next<BR>&gt;Mobile IP 
meeting.&nbsp; <BR>&gt;What is the purpose / goal of this slot ? 
<BR>&gt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2>In SanDiego, we did not have enough 
time to allow people to raise all<BR>their concerns about HMIPv6. This slot is 
intended to provide an<BR>update on the changes in the new version of the WG I-D 
and then open<BR>the floor for a discussion.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2>&gt;Should the authors of the 
different proposals prepare something for<BR>&gt;this meeting?&nbsp; 
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2>The only slide(s) we will have is one 
that shows the changes in the<BR>new version of the HMIPv6 I-D and nothing else. 
There is no intent to<BR>have another presentation of HMIPv6 or anything 
else.<BR>Not really. This slot is for discussion only.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2>&gt;Did I miss something? 
<BR>&gt;thanks, <BR>&gt;<BR>&gt;Claude. <BR>&gt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2>-Basavaraj</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2>&gt;-- 
<BR>&gt;<BR>&gt;----------------------------------------<BR>&gt;Claude 
CASTELLUCCIA, INRIA Rhone-Alpes&nbsp; <BR>&gt;ph:&nbsp; +33 4.76.61.52.15 (fax: 
52.52)<BR>&gt;http://www.inrialpes.fr/planete/<BR>&nbsp; <BR></FONT><FONT 
face=Arial color=#0000ff size=2></FONT></DIV></BODY></HTML>

------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T5248c37995ac12f256079@davir03nok.americas.nokia.com>;
 Wed, 14 Mar 2001 08:54:48 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <GKS5ADR0>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <behcet.sarikaya@usa.alcatel.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHFFFR>; Wed, 14 Mar 2001 09:19:56 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E4301854726@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at =
IETF50</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>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?</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Youngjune Lee Gwon [<A =
HREF=3D"mailto:gyj@dcl.docomo-usa.com">mailto:gyj@dcl.docomo-usa.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, March 13, 2001 5:43 PM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [mobile-ip] Final Agenda for Mobile IP =
WG meeting at IETF50</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Basavaraj,</FONT>
</P>

<P><FONT SIZE=3D2>Can I ask your intention of requesting our =
presentation moving to Seamoby?</FONT>
</P>

<P><FONT SIZE=3D2>Youngjune Gwon</FONT>
<BR><FONT SIZE=3D2>DoCoMo USA Labs</FONT>
</P>

<P><FONT SIZE=3D2>On Tue, 13 Mar 2001, Behcet Sarikaya wrote:</FONT>
</P>

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

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <FV8X7DRF>; Wed, 14 Mar 2001 18:42:28 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC5D@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Mar 2001 09:51:14 -0800 (PST)
Date: Wed, 14 Mar 2001 09:46:40 -0800 (PST)
From: Pat Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
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: <Roam.SIMC.2.0.6.984592000.21137.pcalhoun@nasnfs>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Mar 2001 09:51:14 -0800 (PST)
Date: Wed, 14 Mar 2001 09:46:40 -0800 (PST)
From: Pat Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
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: <Roam.SIMC.2.0.6.984592000.21137.pcalhoun@nasnfs>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <bjorn@lifix.fi>
To: Guangrui Fu <guangruifu@yahoo.com>
Cc: mobile-ip <mobile-ip@sunroof.eng.sun.com>,
        freebsd-net <freebsd-net@FreeBSD.org>,
        freebsd-mobile <freebsd-mobile@FreeBSD.org>
Subject: [mobile-ip] Re: Mobile IP implementation for FreeBSD
Message-ID: <20010314192547.B18619@mymlan.lifix.fi>
Mail-Followup-To: Bjorn Andersson <bjorn@lifix.fi>,
	Guangrui Fu <guangruifu@yahoo.com>,
	mobile-ip <mobile-ip@sunroof.eng.sun.com>,
	freebsd-net <freebsd-net@FreeBSD.org>,
	freebsd-mobile <freebsd-mobile@FreeBSD.org>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <bjorn@lifix.fi>                       +358 50 341 2556
Lifix Systems Oy <http://www.lifix.fi/>                 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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHFFAS>; Wed, 14 Mar 2001 09:15:51 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E430185471B@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] Re: Comments on Regional Registration</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Sorry Charlie but I'm not that sorry. </FONT>
</P>

<P><FONT SIZE=3D2>If four chairs are each missing one leg, they both =
fall down irrespective of which particular leg they are missing.</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>

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

<P><FONT SIZE=3D2>Hello Glenn,</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for your notes.&nbsp; I just have one question =
below,</FONT>
<BR><FONT SIZE=3D2>and then a comment about IPv4 regional =
registration.</FONT>
</P>

<P><FONT SIZE=3D2>Glenn Morrow wrote:</FONT>
</P>

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

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

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

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Charlie P.</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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: <Basavaraj.Patil@nokia.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T5249da701aac12f256079@davir03nok.americas.nokia.com>;
 Wed, 14 Mar 2001 13:59:30 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <GKQMCLF3>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <F1KA1DGD>; Wed, 14 Mar 2001 21:44:25 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC64@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <wsiddiqi@cisco.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9KW95K0>; Wed, 14 Mar 2001 23:25:46 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC68@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Mar 2001 14:35:25 -0800 (PST)
Date: Wed, 14 Mar 2001 14:35:24 -0800 (PST)
From: Youngjune Lee Gwon <gyj@dcl.docomo-usa.com>
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: <Pine.BSI.4.05L.10103141433070.20317-100000@fridge.docomo-usa.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Mar 2001 15:34:52 -0800 (PST)
Date: Wed, 14 Mar 2001 15:30:18 -0800 (PST)
From: Pat Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
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: <Roam.SIMC.2.0.6.984612618.28269.pcalhoun@nasnfs>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Mar 2001 15:37:38 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2ENbZu12801
	for <mobile-ip@sunroof.eng.sun.com>; 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 <charliep@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9Q9TWXD>; Thu, 15 Mar 2001 01:55:49 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC6C@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <hchaskar@hotmail.com>
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: <F181APDVXLuSbh29cM3000000a5@hotmail.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mat@cisco.com>
>Reply-To: mobile-ip@sunroof.eng.sun.com
>To: <Basavaraj.Patil@nokia.com>
>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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <hchaskar@hotmail.com>
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: <F203ApwOLZCHusMjQHt0000009d@hotmail.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mat@cisco.com>
>Reply-To: mobile-ip@sunroof.eng.sun.com
>To: <Basavaraj.Patil@nokia.com>
>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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Mar 2001 17:12:37 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2F1CXL27040
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T524b18d85dac12f256079@davir03nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Wed, 14 Mar 2001 19:47:17 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <GKS5ANSA>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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 <oran@cisco.com>, rcoltun@redback.com
Subject: [mobile-ip] Question to Chairs re: QoS
In-Reply-To: <F203ApwOLZCHusMjQHt0000009d@hotmail.com>
References: <F203ApwOLZCHusMjQHt0000009d@hotmail.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mat@cisco.com>
 > >Reply-To: mobile-ip@sunroof.eng.sun.com
 > >To: <Basavaraj.Patil@nokia.com>
 > >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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Mar 2001 20:05:11 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2F45Ax18181
	for <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <jmalinen@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Mar 2001 20:12:13 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2F4CBl21353
	for <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <jmalinen@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Mar 2001 21:18:47 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2F5IjM23855
	for <mobile-ip@sunroof.eng.sun.com>; 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 <charliep@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <ruppelt@fokus.gmd.de>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T524dde81d3ac12f256079@davir03nok.americas.nokia.com>;
 Thu, 15 Mar 2001 08:42:26 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <GKS5AQVH>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHF0NQ>; Thu, 15 Mar 2001 08:58:57 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E430185511C@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] Re: Comments on Regional Registration</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hesham and Charlie,</FONT>
</P>

<P><FONT SIZE=3D2>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. =
</FONT></P>

<P><FONT SIZE=3D2>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 =
&quot;database in the sky&quot; solutions with AAA protocols to =
this.</FONT></P>

<P><FONT SIZE=3D2>I have an alternate idea which I would like to bring =
up again.</FONT>
</P>

<P><FONT SIZE=3D2>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. </FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>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 &quot;recognize&quot; the particular =
function. </FONT></P>

<P><FONT SIZE=3D2>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. </FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>The advantage of this method are: </FONT>
</P>

<P><FONT SIZE=3D2>- It re-uses the existing binding update i.e. we =
don't burn more air bandwidth. We leverage the existing binding =
updates.</FONT></P>

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

<P><FONT SIZE=3D2>- It does not interfere with the natural routing =
policy of the domains.</FONT>
<BR><FONT SIZE=3D2>- It seems to match up well and re-uses the same =
mechanisms used to monitor bandwidth and signal CoS.</FONT>
</P>

<P><FONT SIZE=3D2>The disadvantages that I see is:</FONT>
</P>

<P><FONT SIZE=3D2>- 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? </FONT></P>

<P><FONT SIZE=3D2>- I agree it is not needed for best effort unless the =
excuse it to solve the security association problems. </FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>Is this clear? It seems to me that doing something =
like this would resolve many issues.</FONT>
</P>

<P><FONT SIZE=3D2>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. </FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Charlie Perkins [<A =
HREF=3D"mailto:charliep@iprg.nokia.com">mailto:charliep@iprg.nokia.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, March 14, 2001 5:38 PM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [mobile-ip] Re: Comments on Regional =
Registration</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hello Hesham,</FONT>
</P>

<P><FONT SIZE=3D2>We want to get the routing part figured out, and I =
believe</FONT>
<BR><FONT SIZE=3D2>we have a pretty good handle on it.</FONT>
</P>

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

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

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Charlie P.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&quot;Hesham Soliman (ERA)&quot; wrote:</FONT>
</P>

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

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHF0ZV>; Thu, 15 Mar 2001 09:07:56 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E4301855143@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] Some questions on Hierarchical MIPv6</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Theo Pagtzis [<A =
HREF=3D"mailto:t.pagtzis@cs.ucl.ac.uk">mailto:t.pagtzis@cs.ucl.ac.uk</A>=
]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, March 14, 2001 7:12 PM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: [mobile-ip] Some questions on Hierarchical =
MIPv6</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi all,</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; I would appreiciate if the HMIP authors =
could shed some light in some statements</FONT>
<BR><FONT SIZE=3D2>in the hmipv6-02 draft that got out recently.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>In extended mode you state that the MN should use as =
CoA (ACoA) the IP of the MAP.</FONT>
<BR><FONT SIZE=3D2>The question is which one the home address or the =
onlink (LCoA)?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>If a MAP is serving as a mobile AR you enforce that =
it must advertise its and all</FONT>
<BR><FONT SIZE=3D2>MAP options available. Does that imply that the =
'preference' is specific here?</FONT>
</P>

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

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

<P><FONT SIZE=3D2>How can you possibly have location privacy if the =
upstream packets have as their</FONT>
<BR><FONT SIZE=3D2>source address the MNs LCoA. If you do not have the =
LCoA as the source address,</FONT>
<BR><FONT SIZE=3D2>then start praying over egress filtering.</FONT>
</P>

<P><FONT SIZE=3D2>If you have load balancing effected which RCoA do you =
send back to the HA?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Regs.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Theo</FONT>
</P>

<P><FONT SIZE=3D2>UCL / Mobile systems</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XA355D>; Thu, 15 Mar 2001 17:07:21 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC78@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHGCZ6>; Thu, 15 Mar 2001 10:17:21 -0600
Message-ID: <9A9367D1556AD21182C40000F80930AB025E56B0@crchy28b.us.nortel.com>
From: "Mohamed Khalil" <mkhalil@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <mkhalil@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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
> 
> 
> 
>  <<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
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] An analysis of the fastv6 draft.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Rajeev,</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>Thx</FONT>
</P>

<P><FONT SIZE=3D2>MK</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: rajeev.koodli@nokia.com [<A =
HREF=3D"mailto:rajeev.koodli@nokia.com">mailto:rajeev.koodli@nokia.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, March 13, 2001 6:41 PM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Cc: rajeev.koodli@nokia.com; =
Charles.Perkins@nokia.com</FONT>
<BR><FONT SIZE=3D2>Subject: [mobile-ip] An analysis of the fastv6 =
draft.</FONT>
</P>
<BR>
<BR>
<BR>

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

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W2T5Y0>; Thu, 15 Mar 2001 18:28:42 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC7C@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <msubbara@cisco.com>
To: mobile-ip@sunroof.eng.sun.com
Cc: Madhavi W Subbarao <msubbara@cisco.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <hgs@cs.columbia.edu>
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 <oran@cisco.com>, rcoltun@redback.com
Subject: Re: [mobile-ip] Question to Chairs re: QoS
References: <F203ApwOLZCHusMjQHt0000009d@hotmail.com> <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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: <Basavaraj.Patil@nokia.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <msubbara@cisco.com>
To: mobile-ip@sunroof.eng.sun.com
Cc: Waseem Siddiqi <wsiddiqi@cisco.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XA39ND>; Thu, 15 Mar 2001 20:31:44 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC7D@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W2T7TH>; Thu, 15 Mar 2001 20:48:40 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC7E@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XA39VQ>; Thu, 15 Mar 2001 21:03:23 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC81@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Mar 2001 12:29:18 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2FKTFb12142
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Mar 2001 17:56:11 -0500 (EST)
Message-ID: <02f201c0ada3$1ef7e190$e1486080@cc.telcordia.com>
From: "William R. Macre" <wmacre@research.telcordia.com>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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" <ruppelt@fokus.gmd.de>
To: <mobile-ip@sunroof.eng.sun.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <pcalhoun@nasnfs.Eng.Sun.COM>
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: <Roam.SIMC.2.0.6.984689442.1274.pcalhoun@nasnfs>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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)" <Hesham.Soliman@era.ericsson.se>
>To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
>List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
>List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
>List-Unsubscribe: 
<mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XA30F8>; Thu, 15 Mar 2001 21:58:35 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC84@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 [ <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 
> 


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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W2T9SC>; Fri, 16 Mar 2001 00:46:14 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC88@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T524f768b98ac12f255079@davir02nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Thu, 15 Mar 2001 16:08:07 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <GKS5A7TC>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Mar 2001 16:05:40 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2G05cn13382
	for <mobile-ip@sunroof.eng.sun.com>; 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" <charliep@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Hesham,

<everyone else, please excuse this relatively content-free note,
 feel free to ignore>


> > 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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XAPARG>; Fri, 16 Mar 2001 01:00:55 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC89@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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)" <Hesham.Soliman@era.ericsson.se>
> >To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
> >List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
> >List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
> >List-Unsubscribe: 
> <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W2T9BJ>; Thu, 15 Mar 2001 23:34:17 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC87@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 [ <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 
> 
> 
> 


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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W2T9X7>; Fri, 16 Mar 2001 01:15:46 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC8A@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W2T9ZR>; Fri, 16 Mar 2001 01:23:16 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC8B@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHGSMX>; Thu, 15 Mar 2001 18:22:51 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43018BA73C@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] Some questions on Hierarchical MIPv6</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>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.</FONT></P>
<BR>
<BR>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>=3D&gt; =
True. But the same goes for any IP adderss in the hierarchical</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>IPv6 =
world. Right ?</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Hesham</FONT>
</P>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W2T98B>; Fri, 16 Mar 2001 01:42:27 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC8C@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T525009c169ac12f254079@davir01nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Thu, 15 Mar 2001 18:48:54 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <GKS5A9PB>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XAPA5Z>; Fri, 16 Mar 2001 01:52:43 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC8D@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W2T0BM>; Fri, 16 Mar 2001 02:04:03 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC8E@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Mar 2001 19:01:24 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2G31NV12537
	for <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <jmalinen@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Mar 2001 19:14:52 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2G3EnT22056
	for <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <jmalinen@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W24ACT>; Fri, 16 Mar 2001 04:40:06 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC91@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W24A11>; Fri, 16 Mar 2001 04:47:05 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC92@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Mar 2001 19:45:50 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2G3joR13449
	for <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <jmalinen@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Mar 2001 20:28:31 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2G4SRn13440
	for <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <jmalinen@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XAPCL9>; Fri, 16 Mar 2001 05:52:04 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC96@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Mar 2001 22:03:26 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2G63P432382
	for <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <jmalinen@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hello,
<p>We actually have a&nbsp; (preliminary) draft that tries to tackle the
problem of route optimal location privacy in MIPv6.
<br>The draft (draft-castelluccia-mobileip-privacy-00.txt) can be retrieved
from my web site : <A HREF="http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-privacy-00.txt">http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-privacy-00.txt</A>
or from the IETF
<br>ID&nbsp;repository...
<p>Note also that we have a new version of HMIPv6 (version 3) that clarifies
some aspects of HMIPv6 and
<br>highlights some of its advantages (see section 6.5 or 6.6 for example).
This new version can be retrieved at:
<br><A HREF="http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt">http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt</A>
<p>comments welcome....
<p>regards,
<p>Claude.
<p>Glenn Morrow wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font size=-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.</font>
<br>&nbsp;
<br>&nbsp;
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font size=-1>=> True. But
the same goes for any IP adderss in the hierarchical</font>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font size=-1>IPv6 world.
Right ?</font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font size=-1>Hesham</font></blockquote>

<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
James Kempf wrote:
<blockquote TYPE=CITE>Hesham,
<p>>> We would like to see elimination of *all* tunnelling overhead over
<br>>> the air (and that includes HA overhead folks) if possible. For example,
<br>>> by stripping it on at the last hop router, where it is no longer
<br>>> needed.
<br>>>
<br>>> Barring that, we would like to see an analysis that indicates header
<br>>> compression will work to eliminate tunnelling overhead, and that
<br>>> it can be moved quickly enough during handover that it will not
<br>>> negate the gains of the low latency handover protocol.
<br>>>
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; => I am not an expert on header
compression by any means
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; but based on my several discussions
with some experts in
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the area, I was told that ROHC
will handle tunnelling
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and Extension headers at no extra
cost over the air.
<br>>
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; So if this true,I wonder if tunnelling
is a problem.
<br>>
<p>Right, the issue isn't whether compression will handle them, it is the
overhead
<br>in reestablishing the state after handover.
<br>&nbsp;</blockquote>
So this is not a problem of HMIPv6...this is a more general problem? You
get this problem
<br>whenever you are performing header compression...
<p>regards,
<br>Claude.
<pre></pre>

<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <ruppelt@fokus.gmd.de>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Hello,
<p>James Kempf wrote:
<blockquote TYPE=CITE>Claude,
<p>>So this is not a problem of HMIPv6...this is a more general problem?
You get
<br>this
<br>>problem
<br>>whenever you are performing header compression...
<br>>
<p>Yes, that's true. HMIP just adds extra header bits. The only additional
<br>complication I could see is if using HMIP would somehow make
<br>convergence of compression after handover slower, or if it would
<br>make it difficult or impossible to do context transfer upon handover
<br>(if that works). Neither are proven, but they are a concern.
<br>&nbsp;</blockquote>
I don't understand why HMIP would make handover slower and/or context
<br>transfer more difficult than MIP....
<br>I really do not understand your concern...do you have something specific
in mind?
<p>thanks,
<p>Claude.
<br>&nbsp;
<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHGWGB>; Fri, 16 Mar 2001 08:05:48 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43018BA836@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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
<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
<http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-0
3.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/ <http://www.inrialpes.fr/planete/> 
  


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D140105413-16032001>Thanks=20
Claude,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D140105413-16032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D140105413-16032001>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.</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Claude =
Castelluccia=20
  [mailto:claude.castelluccia@inrialpes.fr]<BR><B>Sent:</B> Friday, =
March 16,=20
  2001 3:48 AM<BR><B>To:</B> =
mobile-ip@sunroof.eng.sun.com<BR><B>Subject:</B>=20
  [mobile-ip] -HMIPv6 draft + Privacy draft-<BR><BR></DIV></FONT>Hello, =

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

  =
href=3D"http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobile=
ip-hmipv6-03.txt">http://www.inrialpes.fr/planete/people/ccastel/draft-i=
etf-mobileip-hmipv6-03.txt</A>=20

  <P>comments welcome....=20
  <P>regards,=20
  <P>Claude.=20
  <P>Glenn Morrow wrote:=20
  <BLOCKQUOTE TYPE=3D"CITE">&nbsp;=20
    <P><FONT size=3D-1>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.</FONT> <BR>&nbsp; <BR>&nbsp;=20
    <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
size=3D-1>=3D&gt; True. But=20
    the same goes for any IP adderss in the hierarchical</FONT>=20
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=3D-1>IPv6 =
world.=20
    Right ?</FONT>=20
    <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT=20
  size=3D-1>Hesham</FONT></P></BLOCKQUOTE><PRE>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A =
href=3D"http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planet=
e/</A></PRE>&nbsp;=20
</BLOCKQUOTE></BODY></HTML>

------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHGW5H>; Fri, 16 Mar 2001 08:26:59 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43018BA88D@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 [ <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_01C0AE25.271BA500
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] Re: Comments on Regional Registration</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hesham,</FONT>
</P>

<P><FONT SIZE=3D2>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. =
</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>The requirement is to make BU authorization faster, =
more scalable and eliminate the need to send more than one BU over the =
air.</FONT></P>

<P><FONT SIZE=3D2>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.</FONT>
</P>

<P><FONT SIZE=3D2>The last point I made was definitely out of place and =
thank you for pointing that out. </FONT>
</P>

<P><FONT SIZE=3D2>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. </FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Hesham Soliman (ERA) [<A =
HREF=3D"mailto:Hesham.Soliman@era.ericsson.se">mailto:Hesham.Soliman@era=
.ericsson.se</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, March 15, 2001 3:03 PM</FONT>
<BR><FONT SIZE=3D2>To: 'mobile-ip@sunroof.eng.sun.com'</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [mobile-ip] Re: Comments on Regional =
Registration</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hello Glenn,</FONT>
</P>

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

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

<P><FONT SIZE=3D2>Do we want to have a tree-based hierarchy full of =
single </FONT>
<BR><FONT SIZE=3D2>points of failure ?</FONT>
</P>

<P><FONT SIZE=3D2>I don't want any of the above, but I'd like to see =
what others</FONT>
<BR><FONT SIZE=3D2>think.</FONT>
</P>

<P><FONT SIZE=3D2>As you said Light travels fast and I like to Keep it =
simple, </FONT>
<BR><FONT SIZE=3D2>so unless there are strong and well thought =
requirements </FONT>
<BR><FONT SIZE=3D2>for the multi-level hierarchy, I think it should be =
dropped. </FONT>
</P>

<P><FONT SIZE=3D2>I hope you don't take this as a negative response to =
your </FONT>
<BR><FONT SIZE=3D2>proposal, but I like to do things for a reason. The =
reasons </FONT>
<BR><FONT SIZE=3D2>and requirements here are not stated. </FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Hesham</FONT>
</P>

<P><FONT SIZE=3D2>PS: The regional draft for V4, basically says that f =
the MN</FONT>
<BR><FONT SIZE=3D2>has a colocated CoA , then it just registers with =
the </FONT>
<BR><FONT SIZE=3D2>GFA. Sounds familiar ! </FONT>
<BR><FONT SIZE=3D2>Just something to think about.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Glenn Morrow =
[SMTP:gmorrow@nortelnetworks.com]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, 16 March 2001 1:59</FONT>
<BR><FONT SIZE=3D2>&gt; To:&nbsp;&nbsp; =
mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: =
[mobile-ip] Re: Comments on Regional Registration</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hesham and Charlie, </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 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. </FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 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 =
&quot;database in the sky&quot; solutions with AAA protocols to =
this.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I have an alternate idea which I would like to =
bring up again. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 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. </FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 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.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 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 &quot;recognize&quot; the =
particular function. </FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 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. </FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 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.&gt; </FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The advantage of this method are: </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - It re-uses the existing binding update i.e. =
we don't burn more air bandwidth. We leverage the existing binding =
updates.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - It provides the most route optimal form of =
hierarchical mobility. </FONT>
<BR><FONT SIZE=3D2>&gt; - It re-uses the existing security associations =
that SHOULD exist between domains, internal routers and =
hosts.&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; - If one heirarchical router dies other =
communications and hierarchical bindings for other communications that =
mobile is engaged in continue un-affected. </FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - It does not interfere with the natural =
routing policy of the domains. </FONT>
<BR><FONT SIZE=3D2>&gt; - It seems to match up well and re-uses the =
same mechanisms used to monitor bandwidth and signal CoS. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The disadvantages that I see is: </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - 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? =
</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - I agree it is not needed for best effort =
unless the excuse it to solve the security association problems. =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 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.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Is this clear? It seems to me that doing =
something like this would resolve many issues. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 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. </FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 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.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks, </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Glenn </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Glenn </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>&gt; From: Charlie Perkins [ &lt;<A =
HREF=3D"mailto:charliep@iprg.nokia.com">mailto:charliep@iprg.nokia.com</=
A>&gt;] </FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, March 14, 2001 5:38 PM </FONT>
<BR><FONT SIZE=3D2>&gt; To: mobile-ip@sunroof.eng.sun.com </FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [mobile-ip] Re: Comments on =
Regional Registration </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hello Hesham, </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; We want to get the routing part figured out, =
and I believe </FONT>
<BR><FONT SIZE=3D2>&gt; we have a pretty good handle on it. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Setting up security will allow a mobile node to =
provide </FONT>
<BR><FONT SIZE=3D2>&gt; authentication data that can be checked by one =
of the </FONT>
<BR><FONT SIZE=3D2>&gt; anycast group members.&nbsp; I know several =
ways to do that. </FONT>
<BR><FONT SIZE=3D2>&gt; It will be more productive to start on that =
task once two </FONT>
<BR><FONT SIZE=3D2>&gt; other things are out of the way: </FONT>
<BR><FONT SIZE=3D2>&gt; - Fixing the authentication mechanism for base =
Mobile IPv6 </FONT>
<BR><FONT SIZE=3D2>&gt; - Getting the routing part figured out. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If you wish to disqualify all anycast-based =
solutions because </FONT>
<BR><FONT SIZE=3D2>&gt; there are no standards for establishing =
security between a </FONT>
<BR><FONT SIZE=3D2>&gt; node and the members of an anycast group, then =
I would </FONT>
<BR><FONT SIZE=3D2>&gt; just prefer to say that we believe the problem =
is wholly </FONT>
<BR><FONT SIZE=3D2>&gt; solvable for the particular anycast group we =
have designed. </FONT>
<BR><FONT SIZE=3D2>&gt; We don't intend to get in the business of =
solving it for the </FONT>
<BR><FONT SIZE=3D2>&gt; general case. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards, </FONT>
<BR><FONT SIZE=3D2>&gt; Charlie P. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;Hesham Soliman (ERA)&quot; wrote: </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hello Charlie, =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; GM&gt; I agree, I support =
anycast too. To vilify a solution which employs </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; it as magic was wrong and I =
apologize. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; No need for apology, but I wanted to =
point out that this particular </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; use of anycast is easy to implement, =
assuming that one's IPv6 </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; implementation supports anycast at =
all. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D&gt; I'm a bit =
confused by this statement. How can it be easy </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to implement a BU =
to an anycast address ? </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BUs have to be =
secured with AH, so how can you setup this </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; security =
association when there are no standards defined </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to do so ? </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Regards, </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hesham </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHGYAR>; Fri, 16 Mar 2001 09:01:58 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43018BA920@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] Date: Fri, 16 Mar 2001 01:42:26 +0100</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hesham,</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Hesham Soliman (ERA) [<A =
HREF=3D"mailto:Hesham.Soliman@era.ericsson.se">mailto:Hesham.Soliman@era=
.ericsson.se</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, March 15, 2001 6:43 PM</FONT>
<BR><FONT SIZE=3D2>To: 'mobile-ip@sunroof.eng.sun.com'</FONT>
<BR><FONT SIZE=3D2>Subject: [mobile-ip] Date: Fri, 16 Mar 2001 01:42:26 =
+0100</FONT>
</P>
<BR>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>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.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>=3D&gt; I =
agree. The problem is that your IP address is the one piece of </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>information needed to route packets to you. So if you want to =
</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>hide your =
true location by telling the CN to send packets to another</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>IP =
address, then you need to compromise between location</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>privacy =
and optimal routing. </FONT>
</P>

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

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>So, I =
agree it's a hard problem.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&nbsp; =
Hesham</FONT>
</P>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Glenn Morrow wrote:
<blockquote TYPE=CITE><span 
class=180412115-16032001><font face="Arial"><font color="#0000FF"><font size=-1>Claude,</span><span 
class=180412115-16032001></span><span class=180412115-16032001>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".&nbsp;</span><span class=180412115-16032001>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.</font></font></font></blockquote>
If you want to hide your location to your CN, you can either:
<br>-use HMIP (in this case you only reveal your RCoA not your CoA)
<br>- use MIP without route optimization...
<br>-use Mixes, onion routing...
<br>-others?
<p>Anyways you are right, we are not solving this problem in this draft,
we are solving the following one:
<p>-A MN trusts its CN (because they are both belonging to the same company)
<br>and is willing to reveal its CoA, however it does not want anybody
else (for example its
<br>competitor) in the network to know where it is currently located....
<p>This is not possible with MIPv6, this is what our draft tries to solve...
<br>&nbsp;
<p></span><span 
class=180412115-16032001></span><span class=180412115-16032001>
<blockquote TYPE=CITE><font face="Arial"><font color="#0000FF"><font size=-1>Why
would someone bother worrying about eavesdropping and sniffing when one
can simply ping the node after a DNS or other lookup?</font></font></font></span></blockquote>
as I said we make the assumption that a MN only sends BU&nbsp;to CNs it
trusts ....
<br>&nbsp;
<blockquote TYPE=CITE><span 
class=180412115-16032001></span><span 
class=180412115-16032001></span><span class=180412115-16032001><font face="Arial"><font color="#0000FF"><font size=-1>It
seems to me that the recent anonymity extensions to stateless autoconfiguration
will acheive the same functionality as the TMI concept.</font></font></font></span><span 
class=180412115-16032001></span></blockquote>
not really... with the recent anonymity extensions for stateless auto.
you still reveal your network prefix, you just
<br>use an interface identifier that is random...in our case the TMI (128
bit)&nbsp;is completly random....
<blockquote TYPE=CITE><span class=180412115-16032001><font face="Arial"><font color="#0000FF"><font size=-1>More
later on the new HMIP proposal.</font></font></font></blockquote>
this is not a new proposal....just a new version of the old proposal...
<blockquote TYPE=CITE><span class=180412115-16032001><font face="Arial"><font color="#0000FF"><font size=-1>Thanks
for the effort, though.</span></span><span 
class=180412115-16032001></span><span 
class=180412115-16032001></span><span 
class=180412115-16032001>Glenn</font></font></font></span><span 
class=180412115-16032001></span></blockquote>
thanks for your comments...
<blockquote TYPE=CITE><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;
<blockquote style="MARGIN-RIGHT: 0px">
<div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Morrow, Glenn [RICH2:C330:EXCH]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Friday, March 16, 2001
8:06 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> mobile-ip@sunroof.eng.sun.com</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> RE: [mobile-ip] -HMIPv6
draft + Privacy draft-</font></font></div>
<span 
  class=140105413-16032001><font face="Arial"><font color="#0000FF"><font size=-1>Thanks
Claude,</span><span 
  class=140105413-16032001></span><span class=140105413-16032001>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.</font></font></font></span>
<blockquote>
<div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Claude Castelluccia
[<A HREF="mailto:claude.castelluccia@inrialpes.fr">mailto:claude.castelluccia@inrialpes.fr</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Friday, March 16, 2001
3:48 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> mobile-ip@sunroof.eng.sun.com</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> [mobile-ip] -HMIPv6
draft + Privacy draft-</font></font></div>
Hello,
<p>We actually have a&nbsp; (preliminary) draft that tries to tackle the
problem of route optimal location privacy in MIPv6.
<br>The draft (draft-castelluccia-mobileip-privacy-00.txt) can be retrieved
from my web site : <a href="http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-privacy-00.txt">http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-privacy-00.txt</a>
or from the IETF
<br>ID repository...
<p>Note also that we have a new version of HMIPv6 (version 3) that clarifies
some aspects of HMIPv6 and
<br>highlights some of its advantages (see section 6.5 or 6.6 for example).
This new version can be retrieved at:
<br><a href="http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt">http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt</a>
<p>comments welcome....
<p>regards,
<p>Claude.
<p>Glenn Morrow wrote:
<blockquote TYPE="CITE">&nbsp;
<p><font size=-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.</font>
<br>&nbsp;
<br>&nbsp;
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font size=-1>=> True. But
the same goes for any IP adderss in the hierarchical</font>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font size=-1>IPv6 world.
Right ?</font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font size=-1>Hesham</font></blockquote>

<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<a href="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</a></pre>
&nbsp;</blockquote>
</blockquote>
</blockquote>

<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHGZV9>; Fri, 16 Mar 2001 09:44:13 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43018BA9C2@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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
<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
<http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-0
3.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/ <http://www.inrialpes.fr/planete/> 
  


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=180412115-16032001>Claude,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=180412115-16032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=180412115-16032001>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". 
</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=180412115-16032001>You 
want to hide some information from other nodes such&nbsp;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&nbsp;would then be&nbsp;a CN. </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=180412115-16032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=180412115-16032001>Why 
would someone bother worrying about eavesdropping and sniffing when one can 
simply ping the node after a DNS or other lookup?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=180412115-16032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=180412115-16032001></SPAN></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=180412115-16032001>It seems to me that the recent anonymity 
extensions to stateless autoconfiguration will acheive the same functionality as 
the&nbsp;TMI concept.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=180412115-16032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=180412115-16032001>More 
later on the new HMIP proposal. This will take some time.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=180412115-16032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=180412115-16032001><FONT 
color=#0000ff face=Arial size=2><SPAN class=180412115-16032001>Thanks for the 
effort, though.</SPAN></FONT></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=180412115-16032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=180412115-16032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=180412115-16032001>Glenn</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=180412115-16032001></SPAN></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Morrow, Glenn 
  [RICH2:C330:EXCH] <BR><B>Sent:</B> Friday, March 16, 2001 8:06 
  AM<BR><B>To:</B> mobile-ip@sunroof.eng.sun.com<BR><B>Subject:</B> RE: 
  [mobile-ip] -HMIPv6 draft + Privacy draft-<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=140105413-16032001>Thanks Claude,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=140105413-16032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=140105413-16032001>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.</SPAN></FONT></DIV>
  <BLOCKQUOTE>
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Claude Castelluccia 
    [mailto:claude.castelluccia@inrialpes.fr]<BR><B>Sent:</B> Friday, March 16, 
    2001 3:48 AM<BR><B>To:</B> mobile-ip@sunroof.eng.sun.com<BR><B>Subject:</B> 
    [mobile-ip] -HMIPv6 draft + Privacy draft-<BR><BR></DIV></FONT>Hello, 
    <P>We actually have a&nbsp; (preliminary) draft that tries to tackle the 
    problem of route optimal location privacy in MIPv6. <BR>The draft 
    (draft-castelluccia-mobileip-privacy-00.txt) can be retrieved from my web 
    site : <A 
    href="http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-privacy-00.txt">http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-privacy-00.txt</A> 
    or from the IETF <BR>ID&nbsp;repository... 
    <P>Note also that we have a new version of HMIPv6 (version 3) that clarifies 
    some aspects of HMIPv6 and <BR>highlights some of its advantages (see 
    section 6.5 or 6.6 for example). This new version can be retrieved at: 
    <BR><A 
    href="http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt">http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt</A> 

    <P>comments welcome.... 
    <P>regards, 
    <P>Claude. 
    <P>Glenn Morrow wrote: 
    <BLOCKQUOTE TYPE="CITE">&nbsp; 
      <P><FONT size=-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.</FONT> <BR>&nbsp; <BR>&nbsp; 
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=-1>=&gt; True. 
      But the same goes for any IP adderss in the hierarchical</FONT> 
      <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=-1>IPv6 world. 
      Right ?</FONT> 
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
      size=-1>Hesham</FONT></P></BLOCKQUOTE><PRE>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A href="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></PRE>&nbsp; 
  </BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Mar 2001 08:55:25 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2GGtNA24206
	for <mobile-ip@sunroof.eng.sun.com>; 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" <charliep@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <glass@jurassic.Eng.Sun.COM>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <m0th@dcs.shef.ac.uk>
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: <A6BBDA34B0@broadstone.shef.ac.uk>
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: <m0th@dcs.shef.ac.uk>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Mar 2001 09:53:48 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2GHrki32225
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XAQ196>; Fri, 16 Mar 2001 19:02:56 +0100
Message-ID: <BFB4240871E8D411B3FC00508BCF8EAA0E6A49@esealnt453.al.sw.ericsson.se>
From: "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XAQGCS>; Fri, 16 Mar 2001 20:37:16 +0100
Message-ID: <BFB4240871E8D411B3FC00508BCF8EAA0E6A4A@esealnt453.al.sw.ericsson.se>
From: "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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: <BFB4240871E8D411B3FC00508BCF8EAA0E6A4A@esealnt453.al.sw.ericsson.se>
References: <BFB4240871E8D411B3FC00508BCF8EAA0E6A4A@esealnt453.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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T5254256d57ac12f255079@davir02nok.americas.nokia.com>;
 Fri, 16 Mar 2001 13:57:37 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <GKS5BLT7>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHG59D>; Fri, 16 Mar 2001 10:14:15 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43018BAA3F@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] -HMIPv6 draft + Privacy draft-</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>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?</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Michael Thomas [<A =
HREF=3D"mailto:mat@cisco.com">mailto:mat@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, March 16, 2001 9:50 AM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [mobile-ip] -HMIPv6 draft + Privacy =
draft-</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Glenn Morrow writes:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt; Thanks Claude,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt; I'll take a look. I am hoping others will =
follow suit with more candidates</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt; as well. This location privacy thing is =
one of the last &quot;what's missings&quot;. I</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt; have to say I have found it very =
uncomfortable going forward on solutions to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt; other aspects of the problem with this =
issue dangling.</FONT>
</P>

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

<P><FONT SIZE=3D2>&nbsp;&nbsp; I believe that there have been BOF's in =
the past about</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; location (SPACIAL, I think), though I =
didn't attend. The</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; topic does, however, keep coming up. I =
really wonder whether:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; a) this really belongs in MIP WG on the =
one hand</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; b) whether MIP may provide a good =
foundation to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; solve the general =
problem on the other hand</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Mike</FONT>
</P>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <mobile-ip@standards.nortelnetworks.com>;
          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: <pr@hichina.com>
To: mobile-ip@marvin.corpeast.baynetworks.com
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>

 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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <jeremy.huylebroeck@rd.francetelecom.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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"
      <jeremy.huylebroeck@rd.francetelecom.com>

Sent by:  "HUYLEBROECK Jeremy / FTR&D" <jeremy.huylebroeck@rd.francetelecom.com>


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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Mar 2001 13:27:48 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2GLRj721737
	for <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <jmalinen@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Mar 2001 15:01:53 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2GN1qo16053
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Mar 2001 15:26:25 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2GNQMq22206
	for <mobile-ip@sunroof.eng.sun.com>; 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 <charliep@iprg.nokia.com>
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" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <glass@jurassic.Eng.Sun.COM>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXHHH7V>; Fri, 16 Mar 2001 17:36:11 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43018BAF3B@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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
<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
<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
<http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-0
3.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/ <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/ <http://www.inrialpes.fr/planete/> 
  


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=303462123-16032001>Claude,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=303462123-16032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=303462123-16032001>I 
think you might be right on the TMN .&nbsp;If&nbsp;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.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=303462123-16032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=303462123-16032001>BTW - 
I have already read Cellular IP and the HMIP proposals several times. Everytime 
I have time to begin writing down&nbsp;and send suggestions in a clear and 
hopefully&nbsp;un-offensive manner - a new version comes out. 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=303462123-16032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=303462123-16032001>Thanks,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=303462123-16032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=303462123-16032001>Glenn</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Claude Castelluccia 
  [mailto:claude.castelluccia@inrialpes.fr]<BR><B>Sent:</B> Friday, March 16, 
  2001 10:34 AM<BR><B>To:</B> mobile-ip@sunroof.eng.sun.com<BR><B>Subject:</B> 
  Re: [mobile-ip] -HMIPv6 draft + Privacy draft-<BR><BR></DIV></FONT>Glenn 
  Morrow wrote: 
  <BLOCKQUOTE TYPE="CITE"><SPAN class=180412115-16032001><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>Claude,</SPAN><SPAN 
    class=180412115-16032001></SPAN><SPAN class=180412115-16032001>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".&nbsp;</SPAN><SPAN class=180412115-16032001>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.</FONT></FONT></FONT></BLOCKQUOTE>If you want to hide your 
  location to your CN, you can either: <BR>-use HMIP (in this case you only 
  reveal your RCoA not your CoA) <BR>- use MIP without route optimization... 
  <BR>-use Mixes, onion routing... <BR>-others? 
  <P>Anyways you are right, we are not solving this problem in this draft, we 
  are solving the following one: 
  <P>-A MN trusts its CN (because they are both belonging to the same company) 
  <BR>and is willing to reveal its CoA, however it does not want anybody else 
  (for example its <BR>competitor) in the network to know where it is currently 
  located.... 
  <P>This is not possible with MIPv6, this is what our draft tries to solve... 
  <BR>&nbsp; 
  <P></SPAN><SPAN class=180412115-16032001></SPAN><SPAN 
class=180412115-16032001>
  <BLOCKQUOTE TYPE="CITE"><FONT face=Arial><FONT color=#0000ff><FONT 
    size=-1>Why would someone bother worrying about eavesdropping and sniffing 
    when one can simply ping the node after a DNS or other 
    lookup?</FONT></FONT></FONT></SPAN></BLOCKQUOTE>as I said we make the 
  assumption that a MN only sends BU&nbsp;to CNs it trusts .... <BR>&nbsp; 
  <BLOCKQUOTE TYPE="CITE"><SPAN class=180412115-16032001></SPAN><SPAN 
    class=180412115-16032001></SPAN><SPAN class=180412115-16032001><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>It seems to me that the recent 
    anonymity extensions to stateless autoconfiguration will acheive the same 
    functionality as the TMI concept.</FONT></FONT></FONT></SPAN><SPAN 
    class=180412115-16032001></SPAN></BLOCKQUOTE>not really... with the recent 
  anonymity extensions for stateless auto. you still reveal your network prefix, 
  you just <BR>use an interface identifier that is random...in our case the TMI 
  (128 bit)&nbsp;is completly random.... 
  <BLOCKQUOTE TYPE="CITE"><SPAN class=180412115-16032001><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>More later on the new HMIP 
    proposal.</FONT></FONT></FONT></BLOCKQUOTE>this is not a new proposal....just 
  a new version of the old proposal... 
  <BLOCKQUOTE TYPE="CITE"><SPAN class=180412115-16032001><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>Thanks for the effort, 
    though.</SPAN></SPAN><SPAN class=180412115-16032001></SPAN><SPAN 
    class=180412115-16032001></SPAN><SPAN 
    class=180412115-16032001>Glenn</FONT></FONT></FONT></SPAN><SPAN 
    class=180412115-16032001></SPAN></BLOCKQUOTE>thanks for your comments... 
  <BLOCKQUOTE TYPE="CITE"><FONT face=Arial><FONT color=#0000ff><FONT 
    size=-1></FONT></FONT></FONT>&nbsp; 
    <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
      <DIV class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT 
      size=-1>-----Original Message-----</FONT></FONT> <BR><FONT 
      face=Tahoma><FONT size=-1><B>From:</B> Morrow, Glenn 
      [RICH2:C330:EXCH]</FONT></FONT> <BR><FONT face=Tahoma><FONT 
      size=-1><B>Sent:</B> Friday, March 16, 2001 8:06 AM</FONT></FONT> 
      <BR><FONT face=Tahoma><FONT size=-1><B>To:</B> 
      mobile-ip@sunroof.eng.sun.com</FONT></FONT> <BR><FONT face=Tahoma><FONT 
      size=-1><B>Subject:</B> RE: [mobile-ip] -HMIPv6 draft + Privacy 
      draft-</FONT></FONT></DIV><SPAN class=140105413-16032001><FONT 
      face=Arial><FONT color=#0000ff><FONT size=-1>Thanks Claude,</SPAN><SPAN 
      class=140105413-16032001></SPAN><SPAN class=140105413-16032001>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.</FONT></FONT></FONT></SPAN> 
      <BLOCKQUOTE>
        <DIV class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT 
        size=-1>-----Original Message-----</FONT></FONT> <BR><FONT 
        face=Tahoma><FONT size=-1><B>From:</B> Claude Castelluccia [<A 
        href="mailto:claude.castelluccia@inrialpes.fr">mailto:claude.castelluccia@inrialpes.fr</A>]</FONT></FONT> 
        <BR><FONT face=Tahoma><FONT size=-1><B>Sent:</B> Friday, March 16, 2001 
        3:48 AM</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>To:</B> 
        mobile-ip@sunroof.eng.sun.com</FONT></FONT> <BR><FONT face=Tahoma><FONT 
        size=-1><B>Subject:</B> [mobile-ip] -HMIPv6 draft + Privacy 
        draft-</FONT></FONT></DIV>Hello, 
        <P>We actually have a&nbsp; (preliminary) draft that tries to tackle the 
        problem of route optimal location privacy in MIPv6. <BR>The draft 
        (draft-castelluccia-mobileip-privacy-00.txt) can be retrieved from my 
        web site : <A 
        href="http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-privacy-00.txt">http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-privacy-00.txt</A> 
        or from the IETF <BR>ID repository... 
        <P>Note also that we have a new version of HMIPv6 (version 3) that 
        clarifies some aspects of HMIPv6 and <BR>highlights some of its 
        advantages (see section 6.5 or 6.6 for example). This new version can be 
        retrieved at: <BR><A 
        href="http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt">http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt</A> 

        <P>comments welcome.... 
        <P>regards, 
        <P>Claude. 
        <P>Glenn Morrow wrote: 
        <BLOCKQUOTE TYPE="CITE">&nbsp; 
          <P><FONT size=-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.</FONT> <BR>&nbsp; 
          <BR>&nbsp; 
          <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=-1>=&gt; 
          True. But the same goes for any IP adderss in the hierarchical</FONT> 
          <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=-1>IPv6 
          world. Right ?</FONT> 
          <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
          size=-1>Hesham</FONT></P></BLOCKQUOTE><PRE>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A href="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></PRE>&nbsp;</BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><PRE>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A href="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></PRE>&nbsp; 
</BLOCKQUOTE></BODY></HTML>

------_=_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 <mobileip-archive@odin.ietf.org>; 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 <MOBILE-IP@marvin.baynetworks.com>;
          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 <D9QKVTY0>; 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: <D0BFB433B390D411A6B500B0D07C53A1121BA6@flarionmail.lab.flarion.com>
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: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Mar 2001 18:21:42 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2H2LeB19698
	for <mobile-ip@sunroof.eng.sun.com>; 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 <rajeev@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <seamoby@diameter.org>; 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 <rajeev@IPRG.nokia.com>
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 <rajeev@iprg.nokia.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Hello Charlie,
<p>Charlie Perkins wrote:
<blockquote TYPE=CITE>Hello folks,
<p>Here are some suggestions about possible revisions to the
<br>HMIPv6 draft that merit consideration.
<p>- Discussion about smooth handovers (e.g., section 10) should
<br>&nbsp; be deleted.&nbsp; It is not the purpose of a document about
<br>&nbsp; localizing binding update delivery to do that.
<br>&nbsp;</blockquote>
I don't understand why? Why don't you need to worry about smooth
<br>handovers between MAPs? We actually usually standard MIP mechanisms..
<br>this section just clarifies how to use it in the context of HMIPv6....
we should
<br>keep it...
<blockquote TYPE=CITE>&nbsp;
<br>- Load balancing should not be part of HMIPv6.&nbsp; It does not
<br>&nbsp; belong, and the particular methods chosen may need to be
<br>&nbsp; refined independently of the discussion about localizing
<br>&nbsp; the delivery of binding updates.&nbsp; So, for instance, the
<br>&nbsp; 'L' bit should be eliminated.
<p>&nbsp; So, for instance, we may wish to have load balancing in
<br>&nbsp; domains that do not implement any regionalized bindings.
<br>&nbsp; Separation of concerns is important.
<br>&nbsp;</blockquote>
you are right but HMIPv6 (because of the MAP makes it easier
<br>and more efficient....
<blockquote TYPE=CITE>&nbsp;
<br>- There should be only one kind of care-of address, and it</blockquote>
why ?&nbsp;we propose 2 kinds of CoA for different purposes/applications....
<br>Both modes have their own pros and cons (see section 8 for more details...)..
<blockquote TYPE=CITE>&nbsp;
<br>&nbsp; should belong to the node which makes the address look
<br>&nbsp; topologically correct.&nbsp; Thus, a mobile node SHOULD NOT
<br>&nbsp; have an address on the MAP's subnet, unless of course
<br>&nbsp; the mobile node is running applications that appear to
<br>&nbsp; be attached to that network.
<br>&nbsp;</blockquote>
why? Why can't you use an address belonging to the MAP's subnet?
<p>Could you be more specific and give technical reasons...
<blockquote TYPE=CITE>&nbsp;
<br>&nbsp; I think this means that the "basic mode" should be
<br>&nbsp; deleted.&nbsp; Even without the abovementioned considerations,
<br>&nbsp; it is an unnecessary complication to have two modes of
<br>&nbsp; care-of address management for the mobile node.
<br>&nbsp;</blockquote>
both modes are very useful as explained in the draft...if you remove one
of the
<br>modes you just weaken the proposal...unless you give us valid technical
reasons I
<br>will suggest to keep both modes...
<blockquote TYPE=CITE>&nbsp;</blockquote>

<blockquote TYPE=CITE>- How often does the 'M' bit force the mobile node
to re-register
<br>&nbsp; with its home agent?&nbsp; Presumably, not every time the
<br>&nbsp; advertisement is received.
<br>&nbsp;</blockquote>
of course not..only once and then periodically like in MIPv6...
<blockquote TYPE=CITE>&nbsp;
<br>- Section 15 should be deleted.
<br>&nbsp;</blockquote>
In the last version of the draft, Section 15 is the acknowledgements session...
<br>do you actually mean to delete it ;-)
<blockquote TYPE=CITE>&nbsp;
<br>- There should be a very clear statement, perhaps in an
<br>&nbsp; appendix, about exactly which parts of the protocol
<br>&nbsp; specification are covered by Ericsson patents.</blockquote>
I'll let Hesham or Karim answer this point...
<p>Thanks Charlie for your comments eventhough I am not convinced about
their
<br>technical validity (or you need to be more precise ...) ...
<p>regards,
<p>Claude.
<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Alper.Yegin@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Sat, 17 Mar 2001 23:08:16 -0700 (MST)
Received: from eshim by mailbreak.com
	with SMTP (MDaemon.v3.5.2.R)
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Mar 2001 01:07:44 -0500
Message-ID: <016201c0af72$39111fd0$6501a8c0@nyc.solidstreaming.net>
From: "Eunsoo Shim" <eunsoo@ctr.columbia.edu>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Eunsoo Shim" <eunsoo@ctr.columbia.edu>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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" <kempf@heliopolis.eng.sun.com>
To: <mobile-ip@sunroof.eng.sun.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Sat, 17 Mar 2001 23:20:06 -0700 (MST)
Received: from eshim by mailbreak.com
	with SMTP (MDaemon.v3.5.2.R)
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Mar 2001 01:19:08 -0500
Message-ID: <017b01c0af73$d0ac8180$6501a8c0@nyc.solidstreaming.net>
From: "Eunsoo Shim" <eunsoo@ctr.columbia.edu>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Eunsoo Shim" <eunsoo@ctr.columbia.edu>
References: <BFB4240871E8D411B3FC00508BCF8EAA0E6A16@esealnt453.al.sw.ericsson.se>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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)" <Karim.El-Malki@era.ericsson.se>
To: <mobile-ip@sunroof.eng.sun.com>; "'Koichi Ishibashi'"
<ishi@isl.melco.co.jp>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip@marvin.baynetworks.com>;
          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 <karmouch@site.uottawa.ca>
From: Ahmed Karmouch <Karmouch@site.uottawa.ca>
To: karmouch <karmouch@site.uottawa.ca>
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: <Karmouch@site.uottawa.ca>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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
          <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Mar 2001 10:55:46 +0900 
Message-ID: <002401c0b017$56130f80$13e0d5a5@telecom.samsung.co.kr>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <fred@cisco.com>
Subject: Re: [mobile-ip] Question to Chairs re: QoS
Cc: mobile-ip@sunroof.eng.sun.com, Dave Oran <oran@cisco.com>,
        rcoltun@redback.com
In-Reply-To: <15024.9028.54884.980740@thomasm-u1.cisco.com>
References: <F203ApwOLZCHusMjQHt0000009d@hotmail.com>
 <F203ApwOLZCHusMjQHt0000009d@hotmail.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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Mar 2001 13:52:49 +0100 (MET)
Date: Mon, 19 Mar 2001 12:52:39 +0000 (PST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Hierarchical MIPv6 Requirements
To: mobile-ip@sunroof.eng.sun.com
Message-ID: <Roam.SIMC.2.0.6.985006359.20002.nordmark@bebop.france>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
Message-Id: <200103191616.IAA13679@heliopolis.Eng.Sun.COM>
Date: Mon, 19 Mar 2001 10:15:07 -0700
To: <mobile-ip@sunroof.eng.sun.com>, <mobile-ip@sunroof.eng.sun.com>
Cc: "Eunsoo Shim" <eunsoo@ctr.columbia.edu>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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)" <Karim.El-Malki@era.ericsson.se>
>To: <mobile-ip@sunroof.eng.sun.com>; "'Koichi Ishibashi'"
><ishi@isl.melco.co.jp>
>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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Mar 2001 08:35:32 -0800 (PST)
From: James Kempf <kempf@heliopolis.eng.sun.com>
Message-Id: <200103191635.IAA14272@heliopolis.Eng.Sun.COM>
Date: Mon, 19 Mar 2001 10:34:28 -0700
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <pekka.nikander@nomadiclab.com>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fi
MIME-Version: 1.0
To: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
Cc: MobileIP Mailing List <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Mar 2001 11:10:06 -0700 (MST)
Received: from eshim by mailbreak.com
	with SMTP (MDaemon.v3.5.2.R)
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Mar 2001 13:09:08 -0500
Message-ID: <008c01c0b0a0$2bbdf860$96958e3f@nyc.solidstreaming.net>
From: "Eunsoo Shim" <eunsoo@ctr.columbia.edu>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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" <kempf@heliopolis.Eng.Sun.COM>
To: <mobile-ip@sunroof.eng.sun.com>; <mobile-ip@sunroof.eng.sun.com>
Cc: "Eunsoo Shim" <eunsoo@ctr.columbia.edu>
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)" <Karim.El-Malki@era.ericsson.se>
> >To: <mobile-ip@sunroof.eng.sun.com>; "'Koichi Ishibashi'"
> ><ishi@isl.melco.co.jp>
> >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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200103191927.LAA18260@nasnfs.Eng.Sun.COM>
Date: Mon, 19 Mar 2001 11:23:58 -0800
To: "Phillip Neumiller" <neumiller@telocity.com>,
        "Alexandru Petrescu" <Alexandru_Petrescu-AAP021@email.mot.com>
Cc: <mobile-ip@sunroof.eng.sun.com>, <seamoby@cdma-2000.org>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <narten@raleigh.ibm.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <pekka.nikander@nomadiclab.com>
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 <narten@raleigh.ibm.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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W2XHRH>; Mon, 19 Mar 2001 23:34:40 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC9E@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Suggested revisions to HMIPv6
To: charliep@iprg.nokia.com
Cc: "mobile-ip@sunroof.eng.sun.com" <mobile-ip@sunroof.eng.sun.com>
In-Reply-To: "Your message with ID" <3AB2A153.4202E60C@iprg.nokia.com>
Message-ID: <Roam.SIMC.2.0.6.985030069.6952.nordmark@bebop.france>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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 <oran@cisco.com>, 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: <F203ApwOLZCHusMjQHt0000009d@hotmail.com>
	<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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XASJ0F>; Tue, 20 Mar 2001 00:06:25 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCA2@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] IESG security concerns with MIPv6 
In-Reply-To: Message from Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com> 
   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 <narten@raleigh.ibm.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com> 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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <fred@cisco.com>
Subject: Re: [mobile-ip] Question to Chairs re: QoS
Cc: mobile-ip@sunroof.eng.sun.com, Dave Oran <oran@cisco.com>,
        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>
 <F203ApwOLZCHusMjQHt0000009d@hotmail.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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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 <narten@raleigh.ibm.com>
Date: Mon, 19 Mar 2001 16:55:00 -0800 (PST)
CC: Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com>,
        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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

> Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com> 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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <gab@Sun.COM>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "mobile-ip@sunroof.eng.sun.com" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <gab@nasnfs.Eng.Sun.COM>; 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 <gabriel.montenegro@eng.sun.com>; 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 <gab@sun.com>; 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 <gab@sun.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pekka Nikander <pekka.nikander@nomadiclab.com>
CC: IPSEC Mailing List <ipsec@lists.tislabs.com>,
        IPNG Mailing List <ipng@sunroof.eng.sun.com>
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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">

<html>

<head>

   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

   <meta name="GENERATOR" content="Mozilla/4.75 [en] (Win98; U) [Netscape]">

   <title> TWiki . Main . AddressOwnershipAndPrivacyForMipV6  </title>

</head>

<body bgcolor="#FFFFFF">



<h2>

Notes on V6 address ownership problems</h2>

<a href="http://search.ietf.org/internet-drafts/draft-nikander-ipng-address-ownership-00.txt" target="_top">http://search.ietf.org/internet-drafts/draft-nikander-ipng-address-ownership-00.txt</a>

<ul>

<li>

protection against hijacking of valid addresses requires cryptographic

authorization for operations that modify routing (BU's, source routing,

etc)</li>



<li>

quoting from above draft: "Currently there exists no specified mechanism

for proving address ownership in Internet-wide scale."</li>

</ul>

Mini Proposal:

<ul>

<li>

remaining use of <b>redirect</b> operations: they are only allowed with

non-global addresses which are bound (via a cryptographically sound binding)

to <i>anonymous</i> or <i>pseudonymous</i> addresses</li>



<li>

the above constitues perhaps the only rule that operates by default, allowing

any other more dangerous operation only if authorized by strong cryptographic

mechanisms</li>

</ul>



<h2>

Notes on PBK</h2>

<a href="http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt" target="_top">http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt</a>

<ul>

<li>

temporary public/private pair</li>



<li>

EID = hash(publicComponent)</li>



<ol>

<li>

Initiator sends EID to Responder</li>



<li>

Initiator sends publicComponent to Responder</li>

</ol>

</ul>



<dl>

<dl>

<dt>

Note</dt>



<dd>

&nbsp;This exchange must be secure, but it is an improvement over cookies.</dd>

</dl>

</dl>



<ul>

<li>

Initiator sends (BU, EID)Priv to Responder</li>

</ul>

Problems:

<ul>

<li>

does NOT really address the address ownership problem of any publicly routable

addresses</li>



<li>

it is not specified how the EID and public component of the PK are sent

by the initiator to the responder</li>



<li>

preventing hijacking and MIM attacks depend on this sequence if not clearly

specified</li>



<li>

might as well make it secure: use HIP and its sequence</li>

</ul>



<h2>

Notes on simple privacy extension for Mobile IP v6</h2>

<a href="http://search.ietf.org/internet-drafts/draft-castelluccia-mobileip-privacy-00.txt" target="_top">http://search.ietf.org/internet-drafts/draft-castelluccia-mobileip-privacy-00.txt</a>

What it hides: home address in the following two situations:

<ol>

<li>

MN initiated traffic: hides home address from CN (a server?) and eavesdroppers</li>



<li>

CN initiated traffic: hides home addr from eavesdropper (not from CN) What

it <b>does not </b>hide: home address from initiating CN's when the MN

is a server/responder</li>

</ol>

Basics:

<ul>

<li>

MN's instead of their home address use a 128 bit identifier called TMI</li>



<ul>

<li>

digest for TMI' = MD5 ( Home address | digest of TMI )</li>



<li>

define a new TLA (16 bits) for TMI address space</li>



<li>

[why not SHA-1 (also required by IPSEC) given the collision resistance

issues with MD5?]</li>

</ul>

</ul>

Works as follows:

<ol>

<li>

mobile initiator</li>



<ul>

<li>

uses TMI as home address.</li>



<li>

CN sends to <a href="mailto:TMI@COA">TMI@COA</a> (where the addr before

the @ is carried within the home address option</li>

</ul>



<li>

mobile responder</li>



<ul>

<li>

"CN knows the MN's identity by definition" (?)</li>



<li>

[Maybe not, if the CN can initiate to a HIP (or TMI) entity and resolve

the COA by some other means.]</li>



<li>

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.</li>



<li>

traffic MN to CN would be of the form: homeAddr@TMI@COA</li>



<li>

requires a new destination option to carry the real homeAddr</li>



<li>

subsequent packets have just the TMI (essentially an SA), [so why not just

use IPSEC]?</li>

</ul>

</ol>

Still has problems

<ul>

<li>

TMI does not prevent hijacking as explained in the nikander draft on addr

ownership</li>



<li>

this is the problem our new default trust rule addresses (in conjunction

with HIP)</li>



<li>

There may be issues with its use of MD5: <a href="https://central.sun.net/http%3A//cali.france/twiki/bin/view/Main/WeaknessInMd5">WeaknessInMd5</a></li>

</ul>



<h2>

Proposal</h2>

Given that:

<ul>

<li>

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.</li>



<li>

Privacy concerns are also real, and the privacy extensions aim to solve

this.</li>



<li>

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.</li>

</ul>

The obvious solution is to address both:

<ul>

<li>

Privacy</li>



<li>

Address ownership</li>

</ul>

In one common mechanism.

<p>I suggest it be based on HIP:

<ul>

<li>

For all the cases at hand (v6 based) the HIP handshake provides for a <b>very</b>

good and DOS-resistant sequence.</li>



<li>

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.</li>

</ul>

-- <a href="https://central.sun.net/http%3A//cali.france/twiki/bin/view/Main/GabrielMontenegro">GabrielMontenegro</a>

- 18 Mar, 2001 - 12:40:30

<br>&nbsp;

</body>

</html>


--------------6671185CAB32645A5EC3C3B5
Content-Type: text/html; charset=us-ascii;
 name="ProposalToSolveAddressOwnershipAndPrivacyForMipV6.html"
Content-Disposition: inline;
 filename="ProposalToSolveAddressOwnershipAndPrivacyForMipV6.html"
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="GENERATOR" content="Mozilla/4.75 [en] (Win98; U) [Netscape]">
   <title> TWiki . Main . ProposalToSolveAddressOwnershipAndPrivacyForMipV6  </title>
</head>
<body bgcolor="#FFFFFF">

<h1>
Statistical Uniqueness and Cryptographic Verifiability</h1>

<h2>
The Need for a Common Solution</h2>
The idea is to propose one common mechanism that can solve two problems
dealt with in <a href="https://central.sun.net/http%3A//cali.france/twiki/bin/view/Main/AddressOwnershipAndPrivacyForMipV6">AddressOwnershipAndPrivacyForMipV6</a>:
<ul>
<li>
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?</li>

<li>
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).</li>
</ul>
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.
<p>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.
<p>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.
<p>The goal is to arrive at some fundamental assumptions about trust on
top of which one can build some useful communication.
<h2>
Statistically Unique Cryptographically Verifiable ID's (SUCV ID's)</h2>
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?
<p>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:
<ul>
<li>
they are distinguishable from globally routable addresses</li>

<ul>
<li>
they are doled out from a separate TLA (TMI's)</li>

<li>
they have a special form which may include an administrative prefix (HIT's)</li>
</ul>

<li>
because they are based on cryptographic hashes, they are statistically
unique</li>

<ul>
<li>
this, of course, depends on the anti-collision properties of good hash
functions</li>

<li>
perhaps MD5 is to be avoided because of some concerns in this regard: <a href="https://central.sun.net/http%3A//cali.france/twiki/bin/view/Main/WeaknessInMd5">WeaknessInMd5</a>
( <a href="http://www.cs.ucsd.edu/users/bsy/dobbertin.ps" target="_top">http://www.cs.ucsd.edu/users/bsy/dobbertin.ps</a>
)</li>
</ul>

<li>
they are the hashes of a public component of a self-generated Public Key
(perhaps unsigned Diffie-Hellman)</li>
</ul>
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).
<p>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).
<p>Let's call them <b><i>Statistically Unique Cryptographically Verifiable
</i></b>ID's, or SUCV ID's.
<p>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.
<p>Despite the fact that currently there is no way to prove address ownership
in the Internet, these considerations lead to the following fundamental
assumption:
<ul>
<li>
<b>redirect</b> operations are only allowed with SUCV ID's</li>
</ul>
The above constitutes perhaps the only rule that operates by default, allowing
any other more dangerous operation only if authorized by strong cryptographic
mechanisms
<h2>
SUCV ID's versus SUCV Addresses</h2>
What should one use: pure identifiers with no routing significance or addresses?
<p>For example, in the Mobile IPv6 case, a node could just start using
its current care-of address (<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>)
as if it were its home address, and issue binding updates accordingly when
it moved in the future.
<p>Of course, regular&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>'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&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>
address and can rightfully send redirects for it.
<p>The most the node can do is to establish some cryptographic evidence
that it is <i>sitting on </i>that&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>
address. And it is <i>sitting on </i>as opposed to <i>owning </i>, because
the former more accurately describes what is going on (from the CN's point
of view at least, and maybe also in reality).
<p>With a&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>
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&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>,
and later it can prove it is still the same node, but now sitting on another&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>.
<p>But it cannot prove ownership. It may have obtained the&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>
from a DHCP server, for example. Ignoring this subtle distinction leads
to DOS and hijacking attacks.
<p>Problems may also arise because of honest mistakes in configuration.
For example, say node A was originally sitting on&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>,
and then moved on to&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>'.
Suppose it then asks its CN's to redirect traffic to&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>'.
In the meanwhile, the original&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>
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.
<p>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.
<p>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&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>
(and later at another). Furthermore, you do not rely on ingress filtering
to limit exposure.
<p>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&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>'s
that can serve as <b>both an address and as an SUCV ID.</b>
<p>This could be accomplished by:
<ul>
<li>
using the top 64 bits from your routing prefix (as in rfc3041)</li>

<li>
defining the bottom 64 bits as an SUCV ID</li>
</ul>
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&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>.
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.
<p>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.
<h2>
When to use SUCV ID's versus SUCV addresses</h2>
All in all, if one is more concerned about privacy then using an SUCV ID
with no routing significance seems preferable.
<p>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 <i>home addresses
</i>. 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.
<p>This SUCV-ness, by solving the address ownership problem, helps in both
cases:
<ol>
<li>
applications in which routing redirects need to be heeded (of which MIPv6
BU's are but one example), and</li>

<li>
applications in which privacy is the main concern</li>
</ol>
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.
<p>With&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>'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&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>'s
(SU&nbsp;<span STYLE='background : #FFFFCE;'><font color="#0000FF">CoA</span></font><a href="https://central.sun.net/http%3A//cali.france/twiki/bin/edit/Main/CoA">?</a>,
without the CV part) are quite useful (as has been pointed out elsewhere).
<h2>
Proposal for a Solution</h2>
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:
<ul>
<li>
<a href="http://search.ietf.org/internet-drafts/draft-moskowitz-hip-03.txt" target="_top">http://search.ietf.org/internet-drafts/draft-moskowitz-hip-03.txt</a></li>

<li>
<a href="http://search.ietf.org/internet-drafts/draft-moskowitz-hip-arch-02.txt" target="_top">http://search.ietf.org/internet-drafts/draft-moskowitz-hip-arch-02.txt</a></li>

<li>
<a href="http://search.ietf.org/internet-drafts/draft-moskowitz-hip-impl-01.txt" target="_top">http://search.ietf.org/internet-drafts/draft-moskowitz-hip-impl-01.txt</a></li>
</ul>
We assume MIPv6
<ul>
<li>
Use HIP identities, in particular, anonymous HI's</li>

<li>
since we assume v6 here, use HIT the 128 bit long operational representation
of HI's</li>

<li>
HIT takes the place of EID's in PBK or of TMI's in the privacy for mip6
draft</li>
</ul>
TODO: continue this entire section!
<p>-- <a href="https://central.sun.net/http%3A//cali.france/twiki/bin/view/Main/GabrielMontenegro">GabrielMontenegro</a>
- 18 Mar, 2001 - 13:22:02
<br>&nbsp;
</body>
</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Mar 2001 19:39:13 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2K3dB822105
	for <mobile-ip@sunroof.eng.sun.com>; 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 <rajeev@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 
<T5254f3f2e7ac12f254079@davir01nok.americas.nokia.com> for 
<mobile-ip@sunroof.eng.sun.com>;
 Fri, 16 Mar 2001 17:43:11 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <GKQMD2HJ>; Fri, 16 Mar 2001 17:43:11 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4601A659A3@bseis01nok>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Mar 2001 19:46:59 -0800 (PST)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21)
	id <GNKXYXYP>; Mon, 19 Mar 2001 22:46:58 -0500
Message-ID: <D0BFB433B390D411A6B500B0D07C53A1121D37@is~flarionmail.lab.flarion.com>
From: George Tsirtsis <G.Tsirtsis@flarion.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 
<T5254f3f2e7ac12f254079@davir01nok.americas.nokia.com> for 
<mobile-ip@sunroof.eng.sun.com>;
 Fri, 16 Mar 2001 17:43:11 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <GKQMD2HJ>; Fri, 16 Mar 2001 17:43:11 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4601A659A3@bseis01nok>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GTM1TMPH>; Tue, 20 Mar 2001 11:56:20 +0100
Message-ID: <91A311FF6A85D3118DDF0060080C3D82010DCD0C@lat3721.rd.francetelecom.fr>
From: KASSI-LAHLOU Mohammed FTRD/DMI/CAE
	 <mohamed.kassilahlou@rd.francetelecom.fr>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>,
        Claude Castelluccia <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Hello Pekka and thanks for your comments.
<p>Pekka Nikander wrote:
<blockquote TYPE=CITE>Claude,
<p>Here are some half-baked comments to your draft
<br>draft-castelluccia-mobileip-privacy-00.txt
<p>Firstly, I don't immediately see the usability of TMI instead
<br>of just dropping the Home Address altogether, as I suggest
<br>(among other things) in my Homeless Mobile IPv6 draft,
<br>&nbsp; draft-nikander-mobileip-homelessv6-01.txt</blockquote>
The reasons for not dropping the Home Address altogether
<br>are the same that the reasons why we do not encrypt the Home Address
option.
<br>There were some discussions about this issues few weeks ago on the
mailing list...
<br>The reasons of keeping the Home Address (in cleartext) is:
<br>- because IPSec uses it to locate the SA...if you remove the Home Address
<br>option you basically needs to use the CoA and since this CoA changes
you
<br>have to reestablished the SA each time you move...
<br>- because some firewalls use it to perform some kind of filtering...
<blockquote TYPE=CITE>&nbsp;
<br>That is, if you use IPsec, you don't need home
<br>addresses and therefore the home address
<br>destination option is useless.&nbsp; On the other hand, if
<br>IPsec is not used, the home address destination option
<br>may be faked, and its only use is to try to find out the
<br>supposedly right socket that should receive the packet.
<br>However, if there exists an entry in the Binding Cache,
<br>you can use that entry to look up the right home address
<br>anyway, and therefore you don't need the home address.
<br>Thus, the only reason for sending a home address in the
<br>Home Address Destiation Option is to use it for a Binding
<br>Update.&nbsp; But then again, you would be using Ipsec....
<br>Ok, I admit that there is the case where you do not or
<br>cannot send a BU but you still want to use your CoA
<br>as the source address and home address in the dest opt.
<br>However, the only reason for that is ingress filtering,
<br>which is broken IMHO anyway.
<p>Secondly, the method that you propose to create TMIs
<br>actually largely defeats your purpose.&nbsp; That is, if you know
<br>the home address, you can easily calculate the TMI, and you
<br>can still follow the communications as easily as if you
<br>were using the home address.&nbsp; This even applies to the
<br>subsequently generated TMIs.
<br>&nbsp;</blockquote>
In the draft&nbsp; we suggest to generate the TMI as follows:
<br>new TMI = MD5 ( Home address | current TMI),
<p>if the current TMI is initialized with a random value, you won't be
able to
<br>calculate the TMI even if you know the Home Address...
<br>However if you know the current TMI and the home address, you will
<br>be able to compute the next TMI....
<p>We should probably use something like that:
<p>new TMI = MD5 ( Home address | current TMI |&nbsp;random value),
<p>thanks ! We will update the draft...
<blockquote TYPE=CITE>&nbsp;
<br>What comes to security, I think that using TMIs would
<br>make it even harder to authorize BUs.&nbsp; In one way, when
<br>a MN is the client and sends a TMI, it is no different</blockquote>
I&nbsp;am not sure...this depends the address owernship mechanism that
<br>will be used...
<blockquote TYPE=CITE>&nbsp;
<br>from e.g. PBK EIDs.&nbsp; If they are clearly given a separate
<br>address space, as you tentatively suggest, then the
<br>problem might disappear.&nbsp; However, if you allow overlapping
<br>between TMIs and genuine home addresses, you actually
<br>make it very easy to steal traffic destined to specific
<br>home addresses unless you solve the address ownership problem.</blockquote>
we have some ideas on how to do that....
<p>thanks again for your comments,
<p>Claude.
<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
"Hesham Soliman (ERA)" wrote:
<blockquote TYPE=CITE>&nbsp;
<br>> I feel that the group would benefit infinetely if the specs merge...
<br>>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; => "Merging" is not a goal.
The goal should be to highlight
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; what's missing in the current
draft (HMIPv6) and if that
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; missing fuctionality is
stated somewhere else then merging
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; makes sense. So far we haven't
been given a good technical
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reason. The complexity of
mobility management as you mention
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; above does not imply the
need for a multi-level hiearchy.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It is solved with the single
level one in HMIPv6.
<br>&nbsp;</blockquote>

<p><br>I agree with Hesham...
<p>Actually I do no mind merging if that makes sense technically.
<br>What is the goal of the merge?
<br>If there is an other proposal tomorrow will we have to merge too?
<p>We should merge only if this makes sense technically otherwise we might
<br>end up with a monster because the 2 approaches are quite different
....
<p>A better approach might be:
<br>- define the requirements
<br>- evaluate HMIPv6 and Regv6 against these requirements
<br>- and then decide whether it makes sense to merge or not...
<p>I think this is the only way to make some progress...
<p>regards,
<p>Claude.
<br>&nbsp;
<br>&nbsp;
<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXH2PNP>; Tue, 20 Mar 2001 08:32:19 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E4301934F58@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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
<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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001>Claude,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D496361014-20032001>More=20
comments on your privacy draft:</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
<DIV><U><FONT color=3D#800080 face=3DArial size=3D2><A=20
href=3D"http://dailynews.yahoo.com/h/ap/20010319/hl/telemedicine_1.html"=
>http://dailynews.yahoo.com/h/ap/20010319/hl/telemedicine_1.html</A></FO=
NT></U></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001>Generally it seems to me that your solution =
is quite=20
complex&nbsp;for what it is trying to solve - bang for the=20
buck.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D496361014-20032001>You do=20
not give any reasons for why simply dynamically allocating&nbsp;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.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D496361014-20032001>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. </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D496361014-20032001>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.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D496361014-20032001>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.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001>respectfully,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001>Glenn</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2><BR>&nbsp;</DIV></FONT></BLOCKQUOTE></BODY></HTML>

------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
Message-Id: <200103201457.GAA06833@heliopolis.Eng.Sun.COM>
Date: Tue, 20 Mar 2001 08:57:45 -0700
To: <mobile-ip@sunroof.eng.sun.com>, <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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" <kempf@heliopolis.Eng.Sun.COM>
>To: <mobile-ip@sunroof.eng.sun.com>; <mobile-ip@sunroof.eng.sun.com>
>Cc: "Eunsoo Shim" <eunsoo@ctr.columbia.edu>
>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)" <Karim.El-Malki@era.ericsson.se>
>> >To: <mobile-ip@sunroof.eng.sun.com>; "'Koichi Ishibashi'"
>> ><ishi@isl.melco.co.jp>
>> >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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXH2Q5T>; Tue, 20 Mar 2001 09:01:45 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E4301935003@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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
<http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-
privacy-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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D676505314-20032001>Whoops, one more time - wrong link and an =
additional=20
question:</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D676505314-20032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D676505314-20032001>How do=20
you propose to protect against eavesdroppers who discern the COA from =
previous=20
communications?</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D676505314-20032001></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2></DIV></FONT>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001>Claude,</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D496361014-20032001>More=20
  comments on your privacy draft:</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><U><FONT color=3D#800080 face=3DArial size=3D2><A=20
  =
href=3D"http://www.inrialpes.fr/planete/people/ccastel/draft-castellucci=
a-mobileip-privacy-00.txt">http://www.inrialpes.fr/planete/people/ccaste=
l/draft-castelluccia-mobileip-privacy-00.txt</A></FONT></U></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001>Generally it seems to me that your =
solution is quite=20
  complex&nbsp;for what it is trying to solve - bang for the=20
  buck.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D496361014-20032001>You=20
  do not give any reasons for why simply dynamically allocating&nbsp;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.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D496361014-20032001>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. =
</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D496361014-20032001>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.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D496361014-20032001>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.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001>respectfully,</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001>Glenn</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D496361014-20032001></SPAN></FONT>&nbsp;</DIV>
  <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
    <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
    =
size=3D2><BR>&nbsp;</DIV></FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>=


------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hello Gleen,
<p>Glenn Morrow wrote:
<blockquote TYPE=CITE><span 
class=496361014-20032001><font face="Arial"><font size=-1><font color="#0000FF">Claude,</span><span 
class=496361014-20032001></span><span class=496361014-20032001>More
comments on your privacy draft:</span><span 
class=496361014-20032001></span></font><u><font color="#800080"><a href="http://dailynews.yahoo.com/h/ap/20010319/hl/telemedicine_1.html">http://dailynews.yahoo.com/h/ap/20010319/hl/telemedicine_1.html</a></font></u></font></font><span 
class=496361014-20032001></span></blockquote>
I&nbsp;did not write this draft ;-) ...
<br>&nbsp;
<blockquote TYPE=CITE><span 
class=496361014-20032001><font face="Arial"><font color="#0000FF"><font size=-1>Generally
it seems to me that your solution is quite complex for what it is trying
to solve - bang for the buck.</span><span 
class=496361014-20032001></span><span class=496361014-20032001>You
do not give any reasons for why simply dynamically allocating an anonymous
home address is not sufficient.</font></font></font></blockquote>
what is it an "anonymous home address"??? A&nbsp;TMI&nbsp; ;-)
<blockquote TYPE=CITE><font face="Arial"><font color="#0000FF"><font size=-1>How
can someone track someone if they do not know their IP address?</font></font></font></blockquote>
I&nbsp;don't understand what you mean....
<blockquote TYPE=CITE><font face="Arial"><font color="#0000FF"><font size=-1>If
someone is concerned about previous communications they could simple refresh
with a new anonymous address on each communication.</span><span 
class=496361014-20032001></span><span class=496361014-20032001>You
also indicate that IPSEC will have to change in order to use ESP as a protection
mechanisms.</font></font></font></blockquote>
did I say that ?
<blockquote TYPE=CITE><font face="Arial"><font color="#0000FF"><font size=-1>This
is a pretty lame excuse for your solution in that your solution proposes
changes to both ESP and MIP.&nbsp;</font></font></font></span><span 
class=496361014-20032001></span></blockquote>
My draft does not talk about ESP at all...
<blockquote TYPE=CITE><span class=496361014-20032001><font face="Arial"><font color="#0000FF"><font size=-1>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.</span><span 
class=496361014-20032001></span><span class=496361014-20032001>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.</font></font></font></blockquote>

<p><br>&nbsp;what are the other proposals you are talking about?
<p>Our proposal is actually very simple...&nbsp;I am really wondering whether
you've read the right draft ...
<blockquote TYPE=CITE></span><span 
class=496361014-20032001></span><span 
class=496361014-20032001><font face="Arial"><font color="#0000FF"><font size=-1>respectfully,</span><span 
class=496361014-20032001></span><span 
class=496361014-20032001>Glenn</font></font></font></span><span 
class=496361014-20032001></span><span 
class=496361014-20032001></span><span 
class=496361014-20032001></span><span 
class=496361014-20032001></span></blockquote>
thanks for your comments anyway,
<br>regards,
<p>Claude.
<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXH2THK>; Tue, 20 Mar 2001 09:51:01 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E4301935104@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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:
<!--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
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
    <DIV style="MARGIN-RIGHT: 0px"><BR>&nbsp; <BR><SPAN 
    class=496361014-20032001><BR><FONT size=2><FONT color=#0000ff><FONT 
    face=Arial><SPAN class=847352215-20032001>[Morrow, 
    Glenn]</SPAN></FONT></FONT></FONT></SPAN></DIV>
    <DIV style="MARGIN-RIGHT: 0px"><SPAN class=496361014-20032001><FONT 
    size=2><FONT color=#0000ff><FONT face=Arial>Generally it seems to me that 
    your solution is quite complex for what it is trying to solve - bang for the 
    buck.</FONT></FONT></FONT></SPAN><SPAN class=496361014-20032001></SPAN><FONT 
    color=#0000ff><FONT size=2><FONT face=Arial><SPAN 
    class=496361014-20032001>You do not give any reasons for why simply 
    dynamically allocating an anonymous home address is not 
    sufficient.</FONT></FONT></FONT></DIV></BLOCKQUOTE>
  <DIV>what is it an "anonymous home address"??? A&nbsp;TMI&nbsp; ;-) <BR><FONT 
  color=#0000ff face=Arial size=2><SPAN class=847352215-20032001>[Morrow, Glenn 
  ]&nbsp;</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=847352215-20032001>An 
  anonymous&nbsp;home address is an address that would be allocated similar 
  to&nbsp;how anonymous stateless autoconfiguration&nbsp;addresses are 
  allocated.</SPAN></FONT></DIV>
  <BLOCKQUOTE TYPE="CITE"><BR><FONT size=2><FONT color=#0000ff><FONT 
    face=Arial><SPAN class=847352215-20032001>[Morrow, Glenn 
    ]&nbsp;&nbsp;</SPAN>How can someone track someone if they do not know their 
    IP address?</FONT></FONT></FONT></BLOCKQUOTE>I&nbsp;don't understand what you 
  mean.... <BR><FONT color=#0000ff face=Arial size=2><SPAN 
  class=847352215-20032001>[Morrow, Glenn ]&nbsp;If you dynamically and 
  anonymously allocate an address at the home network&nbsp;then there is no long 
  lasting association with a node and this address.</SPAN></FONT>
  <BLOCKQUOTE TYPE="CITE"><BR><FONT size=2><FONT color=#0000ff><FONT 
    face=Arial><SPAN class=847352215-20032001>[Morrow, Glenn 
    ]&nbsp;&nbsp;</SPAN>If someone is concerned about previous communications 
    they could simple refresh with a new anonymous address on each 
    communication.</FONT></FONT></FONT></SPAN><SPAN 
    class=496361014-20032001></SPAN><FONT color=#0000ff><FONT size=2><FONT 
    face=Arial><SPAN class=496361014-20032001>You also indicate that IPSEC will 
    have to change in order to use ESP as a protection 
    mechanisms.</FONT></FONT></FONT></BLOCKQUOTE>
  <DIV>did I say that ? <BR><FONT color=#0000ff face=Arial size=2><SPAN 
  class=847352215-20032001>[Morrow, Glenn ]&nbsp; Quote:</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=847352215-20032001>&lt;!--StartFragment--&gt;<BR>&nbsp;&nbsp; - HA 
  option encryption: An other solution could be to encrypt the<BR>&nbsp;&nbsp; 
  home address option. This solution is not satisfactory because<BR>&nbsp;&nbsp; 
  (1) <STRONG>it would require to modify IPsec implementation </STRONG>(SA 
  should then<BR>&nbsp;&nbsp; be indexed with the care-of address and therefore 
  would need to be<BR>&nbsp;&nbsp; updated at each movement of the mobile node) 
  and (2) it would make<BR>&nbsp;&nbsp; the usage of firewalls difficult 
  (currently firewalls look at the<BR>&nbsp;&nbsp; home address option to 
  perform some filtering). Futhermore this<BR>&nbsp;&nbsp; solution does not 
  solve the problem of incoming packets that<BR>&nbsp;&nbsp; contain a routing 
  header which reveals the home address.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=847352215-20032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=847352215-20032001><FONT color=#0000ff face=Arial size=2><SPAN 
  class=847352215-20032001>[Morrow, Glenn ]&nbsp; 
  Quote:</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=847352215-20032001><FONT color=#0000ff face=Arial size=2><SPAN 
  class=847352215-20032001></SPAN></FONT>&lt;!--StartFragment--&gt;This TMI 
  might be used by the correspondent<BR>&nbsp;&nbsp; node to index the IPsec SA 
  correspondent to the mobile and might be<BR>&nbsp;&nbsp; used by firewalls to 
  do filtering.<BR>&nbsp;</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=847352215-20032001>Oh - 
  so you want to change security anyway.</SPAN></FONT></DIV>
  <BLOCKQUOTE TYPE="CITE"><FONT color=#0000ff face=Arial size=2>This is a 
    pretty lame excuse for your solution in that your solution proposes changes 
    to both ESP and MIP.&nbsp;</FONT></SPAN><SPAN 
    class=496361014-20032001></SPAN></BLOCKQUOTE>
  <DIV>My draft does not talk about ESP at all... <BR><FONT color=#0000ff 
  face=Arial size=2><SPAN class=847352215-20032001>[Morrow, Glenn ]&nbsp;Claude, 
  really - how would you encrypt the HA. I quote again.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=847352215-20032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=847352215-20032001>&lt;!--StartFragment--&gt;The home address option 
  MUST be placed as follows:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - After the 
  routing header, if that header is present<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 
  Before the fragment header, if that header is 
  present<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Before the AH Header or ESP 
  Header, if either one of those<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; headers is 
  present<BR></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=847352215-20032001>&nbsp;</SPAN></FONT></DIV>
  <BLOCKQUOTE TYPE="CITE"><SPAN class=496361014-20032001><BR><FONT 
    size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
    class=847352215-20032001>[Morrow, Glenn ]&nbsp;&nbsp;</SPAN>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.</FONT></FONT></FONT></SPAN><SPAN 
    class=496361014-20032001></SPAN><FONT color=#0000ff><FONT size=2><FONT 
    face=Arial><SPAN class=496361014-20032001>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.</FONT></FONT></FONT></BLOCKQUOTE>
  <P><BR>&nbsp;what are the other proposals you are talking about? <BR><FONT 
  color=#0000ff face=Arial size=2><SPAN class=847352215-20032001>[Morrow, Glenn 
  ]&nbsp;More quotes:</SPAN></FONT></P>
  <P><FONT color=#0000ff face=Arial size=2><SPAN 
  class=847352215-20032001>&nbsp;&lt;!--StartFragment--&gt;3. Possible 
  solutions<BR><BR>&nbsp;&nbsp; Several solutions are possible, all with their 
  limitations:<BR><BR>&nbsp;&nbsp; - IPv6 Privacy Extension: A solution could be 
  to used the privacy<BR>&nbsp;&nbsp; extension described in [1] to configure 
  the home address and<BR>&nbsp;&nbsp; the care-of addresses. While this 
  solution represents a marked<BR>&nbsp;&nbsp; improvement over the standard 
  address configuration methods [2],<BR>&nbsp;&nbsp; and should be used for the 
  home and care-of addresses, we contend<BR>&nbsp;&nbsp; that this is not 
  sufficient.&nbsp; [1] causes nodes to generate<BR>&nbsp;&nbsp; global-scope 
  addresses from interface identifiers that change over<BR>&nbsp;&nbsp; time, 
  even in cases where the interface contains an embedded IEEE<BR>&nbsp;&nbsp; 
  identifier. As a result if [1] is used to generate the home 
  address,<BR>&nbsp;&nbsp; this address will change periodically but the network 
  prefix (64<BR>&nbsp;&nbsp; highest bits) will remain unchanged. This network 
  perfix can still<BR>&nbsp;&nbsp; reveal much information about the mobile 
  node's identity to an<BR>&nbsp;&nbsp; eavesdropper. This mechanism described 
  in [1] must be used for the<BR>&nbsp;&nbsp; home address and care-of address 
  in Mobile IPv6 but one should not<BR>&nbsp;&nbsp; rely on it to get full 
  privacy protection.<BR><BR><BR>C. 
  Castelluccia&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  [Page 3]<BR><BR>Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Privacy Extension for MIPv6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  February,&nbsp; 2001<BR><BR><BR>&nbsp;&nbsp; - HA option encryption: An other 
  solution could be to encrypt the<BR>&nbsp;&nbsp; home address option. This 
  solution is not satisfactory because<BR>&nbsp;&nbsp; (1) it would require to 
  modify IPsec implementation (SA should then<BR>&nbsp;&nbsp; be indexed with 
  the care-of address and therefore would need to be<BR>&nbsp;&nbsp; updated at 
  each movement of the mobile node) and (2) it would make<BR>&nbsp;&nbsp; the 
  usage of firewalls difficult (currently firewalls look at the<BR>&nbsp;&nbsp; 
  home address option to perform some filtering). Futhermore 
  this<BR>&nbsp;&nbsp; solution does not solve the problem of incoming packets 
  that<BR>&nbsp;&nbsp; contain a routing header which reveals the home 
  address.<BR><BR>&nbsp;&nbsp; - IPsec bi-directional Tunnel (mobile VPN): A 
  solution could be to<BR>&nbsp;&nbsp; open a bi-directional IPsec tunnel 
  between the mobile node and its<BR>&nbsp;&nbsp; home agent [3]. This solution 
  has the following disadvantages: (1)<BR>&nbsp;&nbsp; addition of extra 
  bandwidth (packets need to be encapsulated) and<BR>&nbsp;&nbsp; processing 
  overhead, (2) the routing is suboptimal.<BR></SPAN></FONT></P>
  <P>Our proposal is actually very simple...&nbsp;I am really wondering whether 
  you've read the right draft ... <BR><FONT color=#0000ff face=Arial 
  size=2><SPAN class=847352215-20032001>[Morrow, Glenn ]&nbsp;</SPAN></FONT></P>
  <P><FONT color=#0000ff face=Arial size=2><SPAN class=847352215-20032001>I 
  sincerely hope the quotes reduce&nbsp;your wondering and hopefully your 
  wandering.&nbsp;Someone should give you a big KISS.</SPAN></FONT></P>
  <P></SPAN><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=496361014-20032001><SPAN class=847352215-20032001>With 
  less&nbsp;</SPAN>respect,<BR></SPAN></FONT></FONT><SPAN 
  class=496361014-20032001></FONT><BR><FONT size=2><FONT color=#0000ff><FONT 
  face=Arial><SPAN 
  class=847352215-20032001>&nbsp;</SPAN>Glenn</FONT></FONT></FONT></SPAN><SPAN 
  class=496361014-20032001></SPAN><SPAN class=496361014-20032001></SPAN><SPAN 
  class=496361014-20032001></SPAN><SPAN class=496361014-20032001></SPAN></P>
  <P>&nbsp;</P></BLOCKQUOTE></BODY></HTML>

------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Aime.Le-Rouzic@bull.net>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W2Y36T>; Tue, 20 Mar 2001 18:17:06 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCA3@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Mar 2001 11:10:38 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2KJAa405765
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
Message-Id: <200103201954.LAA15017@heliopolis.Eng.Sun.COM>
Date: Tue, 20 Mar 2001 13:53:25 -0700
To: <mobile-ip@sunroof.eng.sun.com>, <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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:
><!--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
>
> 
>




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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Mar 2001 11:58:56 -0800 (PST)
From: James Kempf <kempf@heliopolis.eng.sun.com>
Message-Id: <200103201958.LAA15130@heliopolis.Eng.Sun.COM>
Date: Tue, 20 Mar 2001 13:58:19 -0700
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W2YQ9Q>; Tue, 20 Mar 2001 21:06:57 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCAC@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W2YRA4>; Tue, 20 Mar 2001 21:15:39 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCAD@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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) [ <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. 
> > > > 
> > >         => 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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GMXH2915>; Tue, 20 Mar 2001 14:23:09 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E4355CA0A@crchy271.us.nortel.com>
From: "Rambabu Tummala" <tummala@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>,
        "'Alper.Yegin@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: <tummala@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] rfc3012 question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Alper,</FONT>
</P>

<P><FONT SIZE=3D2>I ran into same problem, only way to get around this =
is by increasing the CHALLENGE_WINDOW to bigger number.&nbsp; In my =
opinion, which defeats the purpose of the draft (RFC) =
itself.</FONT></P>

<P><FONT SIZE=3D2>Let me know, if you have a solution.</FONT>
</P>

<P><FONT SIZE=3D2>Rambabu Tummala</FONT>
<BR><FONT SIZE=3D2>Nortel Networks</FONT>
<BR><FONT SIZE=3D2>ESN 444-8970</FONT>
<BR><FONT SIZE=3D2>External (972)684-8970</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Alper Yegin [<A =
HREF=3D"mailto:Alper.Yegin@eng.sun.com">mailto:Alper.Yegin@eng.sun.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Saturday, March 17, 2001 5:54 PM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: [mobile-ip] rfc3012 question</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hello,</FONT>
</P>

<P><FONT SIZE=3D2>I have a question about how FA can keep track of =
valid challenge values.</FONT>
</P>

<P><FONT SIZE=3D2>As I understand, FA keeps track of valid challenges =
by noting the challenge </FONT>
<BR><FONT SIZE=3D2>values sent in multicast/broadcast RAs (these are =
global, received by all MNs), </FONT>
<BR><FONT SIZE=3D2>and challenge values sent to individual MNs.</FONT>
</P>

<P><FONT SIZE=3D2>It's easy to keep track of challenge values, when =
they are sent in a </FONT>
<BR><FONT SIZE=3D2>registration reply. MN's identity is the key.</FONT>
</P>

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

<P><FONT SIZE=3D2>If the solicited RA is sent multicast/broadcast, then =
since there can be too </FONT>
<BR><FONT SIZE=3D2>many MNs sending RS, this would fill up the =
CHALLENGE_WINDOW very quickly and </FONT>
<BR><FONT SIZE=3D2>create unnecessary rejections.</FONT>
</P>

<P><FONT SIZE=3D2>Unless I'm missing something, this seems like a =
problem.</FONT>
</P>

<P><FONT SIZE=3D2>alper</FONT>
</P>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Mar 2001 13:25:00 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2KLOv118433
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Mar 2001 13:40:37 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2KLeYH11747
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <pekka.nikander@nomadiclab.com>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fi
MIME-Version: 1.0
To: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Mar 2001 22:33:26 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2L6XPg19155
	for <mobile-ip@sunroof.eng.sun.com>; 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 <rajeev@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <pekka.nikander@nomadiclab.com>
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 <mohamed.kassilahlou@rd.francetelecom.fr>
Cc: mobile-ip@sunroof.eng.sun.com,
        Claude Castelluccia <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <pekka.nikander@nomadiclab.com>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fi
MIME-Version: 1.0
To: MobileIP Mailing List <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <charliep@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "'T.J. Kniveton'" <Timothy.Kniveton@nokia.com>,
        Carl Williams <carlw@antley.eng.sun.com>,
        Alper Yegin <Alper.Yegin@eng.sun.com>,
        Brian Zill <bzill@microsoft.com>,
        Mohan Parthasarathy <mobile-ip@sunroof.eng.sun.com>,
        Michael Thomas <mat@cisco.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <pekka.nikander@nomadiclab.com>
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'" <Timothy.Kniveton@nokia.com>,
        Carl Williams <carlw@antley.eng.sun.com>,
        Alper Yegin <Alper.Yegin@eng.sun.com>,
        Brian Zill <bzill@microsoft.com>, Michael Thomas <mat@cisco.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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <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


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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
cc: "'T.J. Kniveton'" <Timothy.Kniveton@nokia.com>,
        Carl Williams <carlw@antley.eng.sun.com>,
        Alper Yegin <Alper.Yegin@eng.sun.com>,
        Brian Zill <bzill@microsoft.com>, Michael Thomas <mat@cisco.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W2Z8C9>; Wed, 21 Mar 2001 23:08:47 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCB2@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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" <kempf@heliopolis.eng.sun.com>
> To: <mobile-ip@sunroof.eng.sun.com>
> 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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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 <dharkins@cips.nokia.COM>
Cc: mobile-ip@sunroof.eng.sun.com,
        "'T.J. Kniveton'" <Timothy.Kniveton@nokia.com>,
        Carl Williams <carlw@antley.eng.sun.com>,
        Alper Yegin <Alper.Yegin@eng.sun.com>,
        Brian Zill <bzill@microsoft.com>, Michael Thomas <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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 <dharkins@cips.nokia.COM>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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
                 <draft-ietf-ipsec-internet-key-00.txt>


                          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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
cc: mobile-ip@sunroof.eng.sun.com,
        "'T.J. Kniveton'" <Timothy.Kniveton@nokia.com>,
        Carl Williams <carlw@antley.eng.sun.com>,
        Alper Yegin <Alper.Yegin@eng.sun.com>,
        Brian Zill <bzill@microsoft.com>
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 <dharkins@cips.nokia.COM>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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
>  >                  <draft-ietf-ipsec-internet-key-00.txt>
>  > 
>  > 
>  >                           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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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 <dharkins@cips.nokia.COM>
Cc: Michael Thomas <mat@cisco.com>, mobile-ip@sunroof.eng.sun.com,
        "'T.J. Kniveton'" <Timothy.Kniveton@nokia.com>,
        Carl Williams <carlw@antley.eng.sun.com>,
        Alper Yegin <Alper.Yegin@eng.sun.com>,
        Brian Zill <bzill@microsoft.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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
 >                  <draft-ietf-ipsec-internet-key-00.txt>
 > 
 > 
 >                           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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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 <dharkins@cips.nokia.COM>
Cc: Michael Thomas <mat@cisco.com>, mobile-ip@sunroof.eng.sun.com,
        "'T.J. Kniveton'" <Timothy.Kniveton@nokia.com>,
        Carl Williams <carlw@antley.eng.sun.com>,
        Alper Yegin <Alper.Yegin@eng.sun.com>,
        Brian Zill <bzill@microsoft.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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
 > >  >                  <draft-ietf-ipsec-internet-key-00.txt>
 > >  > 
 > >  > 
 > >  >                           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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <stroyano@cartuja.us.es>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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?= <Andras.Mehes@era.ericsson.se>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
cc: mobile-ip@sunroof.eng.sun.com,
        "'T.J. Kniveton'" <Timothy.Kniveton@nokia.com>,
        Carl Williams <carlw@antley.eng.sun.com>,
        Alper Yegin <Alper.Yegin@eng.sun.com>,
        Brian Zill <bzill@microsoft.com>
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 <dharkins@cips.nokia.COM>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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
>  > >  >                  <draft-ietf-ipsec-internet-key-00.txt>
>  > >  > 
>  > >  > 
>  > >  >                           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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <H3HYB65P>; Thu, 22 Mar 2001 11:21:30 -0600
Message-ID: <BEF0F85DF631D311B1200000F80932F90518D088@crchy28c.us.nortel.com>
From: "Haseeb Akhtar" <haseeb@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: "'T.J. Kniveton'" <Timothy.Kniveton@nokia.com>,
        Carl Williams <carlw@antley.eng.sun.com>,
        Alper Yegin <Alper.Yegin@eng.sun.com>,
        Brian Zill <bzill@microsoft.com>, Michael Thomas <mat@cisco.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <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
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] Drafty draft about key establishment for Binding Update</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hello all,</FONT>
</P>

<P><FONT SIZE=2>While Pekka's observation is correct, that situation exits today </FONT>
<BR><FONT SIZE=2>irrespective of the Binding Warning message. </FONT>
<BR><FONT SIZE=2>Any potential attacker can send myriad of messages, including </FONT>
<BR><FONT SIZE=2>the Binding Update Option, to the CN.</FONT>
</P>

<P><FONT SIZE=2>I have another question. Are we assuming that the route between</FONT>
<BR><FONT SIZE=2>the CN and HA is safe from man-in-the-middle?</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
</P>

<P><FONT SIZE=2>Haseeb</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Pekka Nikander [<A HREF="mailto:pekka.nikander@nomadiclab.com">mailto:pekka.nikander@nomadiclab.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Wednesday, March 21, 2001 1:32 PM</FONT>
<BR><FONT SIZE=2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=2>Cc: 'T.J. Kniveton'; Carl Williams; Alper Yegin; Brian Zill; Michael</FONT>
<BR><FONT SIZE=2>Thomas</FONT>
<BR><FONT SIZE=2>Subject: Re: [mobile-ip] Drafty draft about key establishment for</FONT>
<BR><FONT SIZE=2>Binding Update</FONT>
</P>
<BR>

<P><FONT SIZE=2>Charlie Perkins wrote:</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Here's what I wrote up last night after our</FONT>
<BR><FONT SIZE=2>&gt; meeting in Salon A.</FONT>
</P>

<P><FONT SIZE=2>As an immediate response, there seems to be a potential new</FONT>
<BR><FONT SIZE=2>DoS attack that may need addressing.&nbsp; That is, when the CN</FONT>
<BR><FONT SIZE=2>receives a Binding Warning, it creates a cookie, and basically</FONT>
<BR><FONT SIZE=2>stores either a &lt;Home Address, Cookie&gt; or a &lt;CoA, Cookie&gt; pair </FONT>
<BR><FONT SIZE=2>to wait for the Binding Update that it expects to receive from </FONT>
<BR><FONT SIZE=2>the MN.&nbsp; It must store this pair since otherwise it couldn't </FONT>
<BR><FONT SIZE=2>turn the Hidden_key into the Key etc.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>Now, a potential attacker could easily send zillions of </FONT>
<BR><FONT SIZE=2>Binding Warnings, using different CoA:s and Home Addresses,</FONT>
<BR><FONT SIZE=2>leading to a DoS similar to TCP SYN flooding.</FONT>
</P>

<P><FONT SIZE=2>Other attacks will follow as soon as I figure out how to do them :-)</FONT>
</P>

<P><FONT SIZE=2>--Pekka</FONT>
</P>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <rgm-ietf@htt-consult.com>
Subject: RE: [mobile-ip] Drafty draft about key establishment for
  Binding Update
In-Reply-To: <BEF0F85DF631D311B1200000F80932F90518D088@crchy28c.us.norte
 l.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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"

<html>
At 11:21 AM 3/22/2001 -0600, Haseeb Akhtar wrote:<br>
<br>
<blockquote type=cite class=cite cite><font size=2>I have another
question. Are we assuming that the route between</font> <br>
<font size=2>the CN and HA is safe from man-in-the-middle?</font>
</blockquote><br>
This was NOT the case on the San Diego wireless where we where having someone trying to do MITH attacks against SSH.<br>
<br>
As wireless deployments go, this becomes more of a problem.<br>
<br>
<br>
</html>

--=====================_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
Message-Id: <200103222001.MAA13448@heliopolis.Eng.Sun.COM>
Date: Thu, 22 Mar 2001 14:02:05 -0700
To: <micke@CS.Arizona.EDU>, <seamoby@cdma-2000.org>, <rohc@cdt.luth.se>,
        <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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: <BEF0F85DF631D311B1200000F80932F90518D088@crchy28c.us.norte
 l.com>
	<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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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.
 > 
 > 
 > <html>
 > At 11:21 AM 3/22/2001 -0600, Haseeb Akhtar wrote:<br>
 > <br>
 > <blockquote type=cite class=cite cite><font size=2>I have another
 > question. Are we assuming that the route between</font> <br>
 > <font size=2>the CN and HA is safe from man-in-the-middle?</font>
 > </blockquote><br>
 > This was NOT the case on the San Diego wireless where we where having someone trying to do MITH attacks against SSH.<br>
 > <br>
 > As wireless deployments go, this becomes more of a problem.<br>
 > <br>
 > <br>
 > </html>


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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
Message-Id: <200103230129.RAA22400@heliopolis.Eng.Sun.COM>
Date: Thu, 22 Mar 2001 19:28:28 -0700
To: "Mikael Degermark" <micke@CS.Arizona.EDU>
Cc: <seamoby@cdma-2000.org>, <rohc@cdt.luth.se>,
        <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <GTM1VHV0>; Fri, 23 Mar 2001 14:31:57 +0100
Message-ID: <91A311FF6A85D3118DDF0060080C3D82010DCD18@lat3721.rd.francetelecom.fr>
From: KASSI-LAHLOU Mohammed FTRD/DMI/CAE
	 <mohamed.kassilahlou@rd.francetelecom.fr>
To: "'Pekka Nikander'" <pekka.nikander@nomadiclab.com>,
        KASSI-LAHLOU Mohammed FTRD/DMI/CAE
	 <mohamed.kassilahlou@rd.francetelecom.fr>
Cc: mobile-ip@sunroof.eng.sun.com,
        Claude Castelluccia
	 <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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'" <Timothy.Kniveton@nokia.com>,
        Carl Williams <carlw@antley.eng.sun.com>,
        Alper Yegin <Alper.Yegin@eng.sun.com>,
        Brian Zill <bzill@microsoft.com>, Michael Thomas <mat@cisco.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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <micke@CS.Arizona.EDU>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Mar 2001 16:04:46 -0500 (EST)
From: "Andrew T. Campbell" <campbell@comet.columbia.edu>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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'" <Timothy.Kniveton@nokia.com>,
        Carl Williams <carlw@antley.eng.sun.com>,
        Alper Yegin <Alper.Yegin@eng.sun.com>,
        Brian Zill <bzill@microsoft.com>, Michael Thomas <mat@cisco.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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <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 :-)
>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W27MYJ>; Sat, 24 Mar 2001 01:40:28 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCB8@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Mar 2001 16:53:40 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2O0rbJ08048
	for <mobile-ip@sunroof.eng.sun.com>; 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 <charliep@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Mar 2001 17:32:43 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2O1Wf621911
	for <mobile-ip@sunroof.eng.sun.com>; 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 <vijayd@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <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


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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Mar 2001 17:56:05 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2O1u2326543
	for <mobile-ip@sunroof.eng.sun.com>; 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 <vijayd@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Mar 2001 18:10:10 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2O2A8122818
	for <mobile-ip@sunroof.eng.sun.com>; 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 <vijayd@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <rajeev@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T52823bc951ac12f257079@davir04nok.americas.nokia.com>;
 Sun, 25 Mar 2001 12:44:34 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <GKS52JPA>; Sun, 25 Mar 2001 12:44:34 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4601A659BF@bseis01nok>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XAX9V4>; Mon, 26 Mar 2001 01:24:47 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCB9@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W277MJ>; Mon, 26 Mar 2001 01:30:47 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCBA@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
cc: "'T.J. Kniveton'" <Timothy.Kniveton@nokia.com>,
        Carl Williams <carlw@antley.eng.sun.com>,
        Alper Yegin <Alper.Yegin@eng.sun.com>,
        Brian Zill <bzill@microsoft.com>, Michael Thomas <mat@cisco.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
cc: "'T.J. Kniveton'" <Timothy.Kniveton@nokia.com>,
        Carl Williams <carlw@antley.eng.sun.com>,
        Alper Yegin <Alper.Yegin@eng.sun.com>,
        Brian Zill <bzill@microsoft.com>, Michael Thomas <mat@cisco.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G01NZFDR>; 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 <jeanmichel.combes@rd.francetelecom.fr>
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 <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G01NZF8N>; 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 <jeanmichel.combes@rd.francetelecom.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <pekka.nikander@nomadiclab.com>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fi
MIME-Version: 1.0
To: Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <pekka.nikander@nomadiclab.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <paul@francis.com>
To: <mobile-ip@sunroof.eng.sun.com>,
        "Mohan Parthasarathy" <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <H3HYDWX5>; Mon, 26 Mar 2001 12:34:16 -0600
Message-ID: <FB4781AB3309D5118DCD00508BF93CA22D8CA8@zrc2c001.us.nortel.com>
From: "Haseeb Akhtar" <haseeb@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <haseeb@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key  establishment for Binding Update)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Folks,</FONT>
</P>

<P><FONT SIZE=2>In addition, the 3GPP has also decided to deploy a AAA protocol </FONT>
<BR><FONT SIZE=2>between the call servers (known as x-CSCF) and the users info</FONT>
<BR><FONT SIZE=2>center (termed HSS for Home Subscriber Server). The current</FONT>
<BR><FONT SIZE=2>leaning is heavily toward Diameter.</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
</P>

<P><FONT SIZE=2>Haseeb</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: James Kempf [<A HREF="mailto:kempf@heliopolis.eng.sun.com">mailto:kempf@heliopolis.eng.sun.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Monday, March 26, 2001 12:22 PM</FONT>
<BR><FONT SIZE=2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=2>Subject: Re: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key</FONT>
<BR><FONT SIZE=2>establishment for Binding Update)</FONT>
</P>
<BR>

<P><FONT SIZE=2>Mike,</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; &gt; &gt;Sorry for the confusion. I was summarizing the IESG (and others) concerns</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;about using AH for solving the mobile IPv6 security problem.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;I did not mean to use the word &quot;scale&quot;. Hence, if we don't want to use AH</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;and not solve the authorization problem, why can't we just use the IKE</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;part alone ? If this is also considered heavy weight, all new solutions</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;should be compared against this. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I won't presume to say I can contribute much to the security discussion, but</FONT>
<BR><FONT SIZE=2>&gt; &gt; one concern with IKE is deployment. Some network operators may not</FONT>
<BR><FONT SIZE=2>&gt; &gt; want to deploy IKE. Alternative solutions for key distribution (such</FONT>
<BR><FONT SIZE=2>&gt; &gt; as AAA) may be more desirable.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; Whatever the solution is, it better not rely on</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; AAA exclusively. There is no requirement that AAA</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; be run uniformly. In fact, a pretty large percentage</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; of the devices on the net in the here and now do </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; not use AAA _at all_. The one I'm typing on right </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; now is a fine example.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
</P>

<P><FONT SIZE=2>I did not say that it should be used exclusively, only that IKE should</FONT>
<BR><FONT SIZE=2>not be the only solution due to concerns about widespread</FONT>
<BR><FONT SIZE=2>deployment.</FONT>
</P>

<P><FONT SIZE=2>With regard to how many devices will use AAA, both</FONT>
<BR><FONT SIZE=2>3GPP and 3GPP2 have recently standardized on the IETF AAA architecture</FONT>
<BR><FONT SIZE=2>for their all IP core networks. 3GPP2 is in the process of deploying</FONT>
<BR><FONT SIZE=2>AAA for mobile IPv4 in their current IOS v4.x with Radius as the protocol,</FONT>
<BR><FONT SIZE=2>and in Version C, to be standardized this summer, they intend to</FONT>
<BR><FONT SIZE=2>employ Diameter. I believe it is a fair assessment to say that AAA will likely</FONT>
<BR><FONT SIZE=2>be widely deployed in telephony networks in the future. </FONT>
</P>

<P><FONT SIZE=2>Perhaps you have some information about similar deployment plans for IKE</FONT>
<BR><FONT SIZE=2>that motivated your statement? If so, perhaps you could share it?</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>jak</FONT>
</P>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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 <pekka.nikander@nomadiclab.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Samita.Chakrabarti@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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: <FB4781AB3309D5118DCD00508BF93CA22D8CA8@zrc2c001.us.nortel.com>
References: <FB4781AB3309D5118DCD00508BF93CA22D8CA8@zrc2c001.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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Mar 2001 12:01:48 -0700 (MST)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id <HQBRMZMM>; Mon, 26 Mar 2001 13:56:48 -0500
Message-ID: <CD8355C7E19ED411BD5F00508BB0D19D1C5588@mail.megisto.com>
From: Phil Roberts <PRoberts@MEGISTO.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Mar 2001 11:39:31 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2QJdT512671
	for <mobile-ip@sunroof.eng.sun.com>; 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" <TJ@Kniveton.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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 <dharkins@cips.nokia.COM>
Cc: Michael Thomas <mat@cisco.com>, mobile-ip@sunroof.eng.sun.com,
        "'T.J. Kniveton'" <Timothy.Kniveton@nokia.com>,
        Carl Williams <carlw@antley.eng.sun.com>,
        Alper Yegin <Alper.Yegin@eng.sun.com>,
        Brian Zill <bzill@microsoft.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <paul@francis.com>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Mar 2001 13:55:58 -0800 (PST)
Date: Mon, 26 Mar 2001 13:55:57 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
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: <Roam.SIMC.2.0.6.985643757.13603.pcalhoun@nasnfs>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <charliep@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <pcalhoun@eng.sun.com>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
References: <Roam.SIMC.2.0.6.985643757.13603.pcalhoun@nasnfs>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Samita.Chakrabarti@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <charliep@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Francis <paul@francis.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <paul@francis.com>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <charliep@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Francis <paul@francis.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <HQ92RYQW>; Mon, 26 Mar 2001 16:29:08 -0800
Message-ID: <4148FEAAD879D311AC5700A0C969E890049A2AC6@orsmsx35.jf.intel.com>
From: "Iyer, Prakash" <prakash.iyer@intel.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <paul@francis.com>
To: "Charlie Perkins" <charliep@iprg.nokia.com>
Cc: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <paul@francis.com>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <paul@francis.com>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W29L3Q>; Tue, 27 Mar 2001 08:32:42 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCC7@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'Samita Chakrabarti'" <Samita.Chakrabarti@eng.sun.com>,
        mobile-ip@sunroof.eng.sun.com
Cc: claude.castelluccia@inria.fr,
        "Karim El-Malki (ERA)"
	 <Karim.El-Malki@era.ericsson.se>,
        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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <paul@francis.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <Roam.SIMC.2.0.6.985643757.13603.pcalhoun@nasnfs>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XAZ363>; Tue, 27 Mar 2001 08:52:12 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCC8@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: "'paul@francis.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <paul@francis.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <Roam.SIMC.2.0.6.985643757.13603.pcalhoun@nasnfs> <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: "Charlie Perkins" <charliep@iprg.nokia.com>
To: "Pat Calhoun" <pcalhoun@eng.sun.com>
Cc: <mobile-ip@sunroof.eng.sun.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <claude.castelluccia@inrialpes.fr>
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'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Hello,
<p>An other "short-term" alternative would be to use HMIPv6 with pre-shared
keys...
<br>i.e. the MN&nbsp;has pre-shared keys with the MAPs it usually visits
(i.e. its MAP at work, at home, ....).
<p>This would work as follows:
<br>1-The MN discovers a MAP as specified in the HMIPv6 draft
<br>2-if the MN&nbsp;has a pre-shared key with this MAP, it registers with
it and registers its RCoA
<br>with its HA
<br>3-if the MN&nbsp;does not have a pre-shared key it then uses Mobile
IPv6 (without RO)
<p>I&nbsp;think this is a pretty good tradeoff ....
<p>regards,
<p>Claude.
<p>"Hesham Soliman (ERA)" wrote:
<blockquote TYPE=CITE>Hello Paul,
<p>Good to see you on this list :)
<br>I haven't formed an opinion on either way, but
<br>it is worth noting that the scenario you mention
<br>is possible/valid and can be supported with HMIPv6 as follows:
<p>1. The MN discovers a MAP as specified in the draft
<br>2. The MN gets an SA with the MAP using the AAA
<br>&nbsp;&nbsp;&nbsp; infrastructure
<br>3. The MN registers with the MAP
<br>4. The MN uses DynDNS or SIP to register its Home
<br>&nbsp;&nbsp;&nbsp; address.
<p>Which is what you were saying (I think) anyway.
<p>We have some framework draft for key generation
<br>/distribution using the AAA infrastructure
<p><a href="http://search.ietf.org/internet-drafts/draft-soliman-mobileip-routeopt-mipv6-01.txt">http://search.ietf.org/internet-drafts/draft-soliman-mobileip-routeopt-mipv6-01.txt</a>
<p>However, you could argue the opposite also and say that
<br>the amount of time it would take to get this into a standard
<br>protocol (the AAA bit) can also be spent into developing a
<br>key distribution mechanism for the basic spec.
<br>The other disadvantage would be that it won't work if there
<br>is no AAA.
<p>This is not an ad for the drafts I'm doing but I thought it
<br>was worth noting the pros and cons
<p>Cheers,
<br>Hesham
<p>> -----Original Message-----
<br>> From: Paul Francis [SMTP:paul@francis.com]
<br>> Sent: Tuesday, 27 March 2001 2:54
<br>> To:&nbsp;&nbsp; Charlie Perkins
<br>> Cc:&nbsp;&nbsp; mobile-ip@sunroof.eng.sun.com
<br>> Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: [mobile-ip] MIPv6 security
issues:&nbsp; how to move forward
<br>>
<br>> >
<br>> > Well, I guess that this is a good example of how offense can be
<br>> > taken where none was meant at all.&nbsp; However, I realize that
with
<br>>
<br>> Or, a good example of how careless wording can lead to offense.
<br>>
<br>> > all the upheaval about Mobile IPv6, one could imagine a very long
<br>> > delay.&nbsp; My belief is that we can avoid that delay.
<br>>
<br>> Understood.
<br>>
<br>> >
<br>> > Did you see my earlier note to the [mobile-ip] mailing list?&nbsp;
In case
<br>> > not, I'll repeat myself here:
<br>>
<br>> I did see it.
<br>>
<br>> > >
<br>> > > I did, in fact, suggest that we should move forward without specifying
<br>> > > a method by which the mobile node and correspondent node would
<br>> > > develop a security association.&nbsp; That suggestion was denied.&nbsp;
To change
<br>> > > the specification by eliminating the Binding Update would be
very hard,
<br>> > > and almost pointless since it's needed for the home agent.
<br>>
<br>> Nobody (as far as I know, certainly not me) ever suggested that we
get rid
<br>> of the binding update, for the very reason you state.&nbsp; Only
that we consider
<br>> separating route optimization from the rest of MIPv6 so that the
route
<br>> optimization part doesn't continue to delay moving forward with this
<br>> critical standard.
<br>>
<br>> >
<br>> > So the current plan is to build a special purpose key establishment
<br>> > protocol, which looks doable given the design parameters.
<br>>
<br>> Absolutely.&nbsp; I notice that there does not appear to be concensus
of what
<br>> those design parameters are.
<br>>
<br>> >
<br>> > I do not believe that a wholesale rejustification of the basic
<br>> > protocol is needed. Furthermore (again repeating myself):
<br>>
<br>> Wow you are putting a lot of words in my mouth that never came out
in the
<br>> first place.&nbsp; I don't think separating off route optimization
amounts to a
<br>> whole rejustification of the basic protocol.
<br>>
<br>> >
<br>> > In an earlier note, I said:
<br>> >
<br>> > >&nbsp; ....&nbsp;&nbsp; getting the home agent out of the typical
routing path, is an
<br>> > >&nbsp; important aspect of the scalability of the protocol.
<br>>
<br>> I said I want to hear *why not*.&nbsp; The above statement is simply
a
<br>> re-affirmation that you believe route optimization is important.&nbsp;
I have
<br>> said it may not be important because in most cases upon power up
a mobile
<br>> can get a home address from the visited domain and therefore is not
very far
<br>> from its (adopted) HA.
<br>>
<br>> This is my position, so if you want to explain why this is wrong,
you can't
<br>> just repeat your base position...you have to justify it.
<br>>
<br>> >
<br>> > We need to design this for billions of nodes.
<br>>
<br>> It doesn't matter if you have one node that rarely needs route optimization
<br>> or a billion nodes that rarely need route optimization.&nbsp; Either
way route>
<br>> optimization is rarely needed.
<br>>
<br>> Finally, I'm not exactly saying that we don't need route optimization,
just
<br>> that moving forward without is a better strategy than risking further
delay
<br>> of the whole spec.&nbsp; We absolutely need basic MIPv6 today.&nbsp;
We can optimize
<br>> it later when we know how.
<br>>
<br>> Put another way, we have four possibilities:
<br>>
<br>> 1. MIPv6 very soon with no route optimization, route optimization
later
<br>> 2. MIPv6 very soon with route optimization
<br>> 3. MIPv6 delayed with no route optimization
<br>> 4. MIPv6 delayed with route optimization.
<br>>
<br>> I'm saying that 1 is the safest and most prudent bet right now, even
at a
<br>> risk of 3.&nbsp; You are saying that going for 2 is better, even
at a risk of 4.
<br>> I think 1 is safer and more prudent because I think the probability
of 4 is
<br>> much higher than the probability of 3.
<br>>
<br>> PF
<br>></blockquote>

<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <claude.castelluccia@inrialpes.fr>
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Hello Samita and thanks a lot for your comments concerning HMIPv6.
<p>We'll take your comments into consideration for the next version of
the draft
<br>(some of them are already integrated in the 03 version... (<A HREF="http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt">http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt</A>)
<p>Concerning the third mode proposal, i have 3 comments:
<p>-in the basic mode, the MAP&nbsp;is nothing more that a HA.&nbsp; This
was one of our requirements
<br>when designing this mode. The basic mode is very simple to implement...
adding the fonctionality
<br>you are proposing would require to modify the MAP and we won't be able
to use a HA as MAP anymore...
<p>-in your proposal, the MAP modifies the destination address of the packets
that are sent to a Mobile host.
<br>What will happen if the packet is authenticated with AH? The packets
will be rejected by the MN. This
<br>is an issue when the CN&nbsp;is also mobile and piggybacks&nbsp; its
BUs with its packets (the whole packets must then be
<br>authenticated with AH) ...
<p>- Most of wireless networks will use RoHC (as confirmed by Hesham email)
so I don't see the motivation
<br>for this 3rd mode (considering the 2 previous issues).
<p>Thanks again for your comments,
<p>regards,
<p>Claude.
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p>Samita Chakrabarti wrote:
<blockquote TYPE=CITE>Hello:
<p>Sorry for the late posting... But&nbsp; most of the comments have been
discussed with
<br>hmipv6 authors in private emails.
<p>The comments are based&nbsp; mostly on hmipv6 version 2 draft.
<br>Also, I'd like to propose a third mode in hmipv6 especially
<br>for those systems which do not have ROHC implementation
<br>at their network.
<br>Thus this proposed mode will save 40 bytes of tunnel overhead
<br>between MAP and mobile node in the basic mode. I understand that
<br>this would be useful for IPRAN&nbsp; as James Kempf had pointed out
<br>earlier in the list.
<p>Editorial comments:
<p>section 3.0 : one or two word description of 'B' flag would be helpful
<p>section 3.1 : Load-balancing sub-option : needs more clarification as
to where the
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sub-option is sent ( to MAP only or CN as well ?)
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Load-balancing may be a misnomer, perhaps a more suitable name should
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
be used as this option basically is used by the MN for balancing load
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
over different interfaces. But the load-balancing is dependent on the
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
flow policies. So, how about "Policy" sub-option or other suitable names
?
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
How about changing 'prot number' to 'proto number' ?
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Needs description for dest-port, r and Destination address, I suppose
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
destination address should be LCOA
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
'P' bit description should clarify which "ip-address" (LCOA?) is used
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
to identify flow.
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Since checking for flow-label or port-ipaddr pair also involve checking
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
each packet at MAP, 'per-packet' load balancing description is a bit
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
confusing in this context. Since 'per-packet' load-balancing refers to
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
'A' bit only, another beeter name or more clarification required here.
<p>Section 4.0&nbsp;&nbsp;&nbsp; An example of 'T' bit would help
<p>Section 5.0&nbsp;&nbsp;&nbsp; A little more detailed analysis of choices
of MAP discovery will be
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
a good guide for implementors and users to pick which one to pick
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
in their implementation/operating environment.
<br>&nbsp;
<p>Section 5.4:&nbsp;&nbsp; 3rd paragraph mentions :
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"If a MN has access to several ARs.......it's current MAP"
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
an example will be helpful in order to describe this scenario.
<br>Section 11:&nbsp;&nbsp;&nbsp; Needs more clarification ( I was told
that version 3 has improved texts)
<p>Section 15:&nbsp;&nbsp; Reference for AAAv6 should be recorded.
<p>Technical :
<br>----------
<br>&nbsp;(Some of the following are discussed with hmipv6 authors)
<p>Section 3.1 : 'r' bit may be moved adjacent to F|P|A flags for future
use ?
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Next version of draft should also specify possible error codes--
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
at least the 'errors in text form'.
<p>Section 5&nbsp; :&nbsp; For simplicity, hmipv6 draft should limit the
choices of MAP discovery
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
and specify one or two options as 'MUST' to implement. Otherwise,
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
implementations either will become too complex or will not interoperate.
<p>Section 6.1 : Please specify that alternate COA sub-option is optional
when RCOA is
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
used as source address of the BU. (for location privacy)
<p>Section 11 : This section should also mention that the hierarchical
network between
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MAP and MNs must be a trusted network and no src-address filtering is done
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
on the outging packets from the mobile nodes.
<p>Section 7.1 and 7.2 :
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Added operation in HA can be easily avoided if :
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
A MN MUST (instead of SHOULD) send a BU for each different Home-addr it
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
uses for connection.
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
But I think, having HA to add RH in the outer IP layer, has two
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
advantages:
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1) less signalling between MN and AR ( this is probably desirable by
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
wirelss vendors)
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2) Supporting site-local addressed home-addr in the foreign domain.
<p>Load Balancing in general:
<br>BTW, a detailed load balancing scheme for fault-tolerance for MAP should
be schetched
<br>out so that the backup MAP can takes over when the orginial MAP goes
down. Perhaps the
<br>policy and MAP load babalncing scenarios should be discussed in a separate
draft to
<br>keep this draft simple. But we can toss ideas and discuss more on that
in the
<br>discussion team.
<p>Proposal of having optional 3rd mode(Basic-non-tunneled) in a hierarchical
network where
<br>ROHC is not available.
<p>Basic non-tunnel mode: Supporting mobile nodes with RCOA without tunnels
between MAP and MN
<p>MAP Operation:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In this
mode, MAP recives BU and sends BAck after performing DAD operation
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as described
in basic mode. A new bit will be introduced in the MAP advertisement
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to distinguish
"Basic non-tunnel" mode service from other two modes.
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The new MAP option format ( as per discussion
with Hesham Soliman):
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; Length&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; Distance&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Pref&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Plen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|R|M|T|N|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Reserved&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Valid Lifetime&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Global IP Address for MAP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; N&nbsp; - Indicates
that the MN MUST be able to replace the destination
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
address of incoming packet from LCOA to RCOA when the packets
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
are coming from either a correspondent node or it's home agent.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
R bit MUST be set when N bit is set. N bit MUST not be set
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
when M is bit is set. Basicaly N bit is an indication of MAP
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
supporting basic-non-tunnel mode.
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The MAP
keeps a binding cache containing association
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of RCOA,
LCOA and MN's home-addr. It intercepts the packets that are destined
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to RCOA
(either from HA or from CN. Note that in basic mode RCOA is different
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from MAP's
own address.) MAP then replaces the destination IP-address RCOA by
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LCOA after
looking up the binding cache, and simply forwards the packet to
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the topologically
correct router in the hierarchy.
<p>MN Operations:
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MN forms
LCOA and RCOA exactly the same way as described in basic mode. It also
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sends
BU to MAP and home agent subsequently exactly the same way as described
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in 6.1
(Basic mode MN operations). MN may also send BU to CN informing RCOA as
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; it's new
COA ( same as in basic-mode operation).
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MN receives
packets addressed to MN's LCOA address, MN replaces the LCOA address
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; by the
corresponding RCOA address after determining that this packet is
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; coming
from either it's home agent or correspondent node. MN then proceeds
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with normal
processing of packets as described in base mobile IPv6 draft.
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The differnce
between basic mode MN and basic-non-tunnel mode MN is that
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the latter,
does not need to detunnel the packet from MAP at all. Instead it
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; swaps
the destination address of the incoming&nbsp; packet when the
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; source
address is home agent address or&nbsp; correspondent node address.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Thus a
mobile node implementation may maintain a list of CNs and
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Home agents
for address verification.
<p>HA Operation:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No change
from basic mode operation.
<p>----------------------------------------------------------------------------------------
<p>Thanks,
<br>-Samita</blockquote>

<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
cc: Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
cc: Pekka Nikander <pekka.nikander@nomadiclab.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Mar 2001 01:41:21 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2R9fJr12203
	for <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <jmalinen@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <ks51@ukc.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
cc: Paul Francis <paul@francis.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <MOBILE-IP@marvin.baynetworks.com>;
          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 <Limor.Elbaz@discretix.com>
To: ietf-tls <ietf-tls@lists.certicom.com>, ipsec <ipsec@lists.tislabs.com>,
        MOBILE-IP@marvin.corpeast.baynetworks.com, ssl <ssl@engine.ca>
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: <Limor.Elbaz@discretix.com>
X-Orig: <ronyoung@nortelnetworks.com>
X-Orig: <ronyoung@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Mar 2001 04:33:35 -0700 (MST)
Received: from eshim by mailbreak.com
	with SMTP (MDaemon.v3.5.2.R)
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Mar 2001 06:32:30 -0500
Message-ID: <012401c0b6b2$2d33d760$6501a8c0@nyc.solidstreaming.net>
From: "Eunsoo Shim" <eunsoo@ctr.columbia.edu>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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" <charliep@iprg.nokia.com>
To: "Glenn Morrow" <gmorrow@nortelnetworks.com>
Cc: <mobile-ip@sunroof.eng.sun.com>
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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Jari.Arkko@lmf.ericsson.se>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W20BT2>; Tue, 27 Mar 2001 14:26:57 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCCC@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
cc: "'paul@francis.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
cc: "'paul@francis.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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'" <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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Mar 2001 07:14:48 -0800 (PST)
Date: Tue, 27 Mar 2001 07:14:46 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
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: <Roam.SIMC.2.0.6.985706086.9959.pcalhoun@nasnfs>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <sjj0@gte.com>
Subject: Re: Scalability [Was Re: [mobile-ip] Drafty draft about key
  ... 
In-Reply-To: <200103271450.f2REonA77475@givry.rennes.enst-bretagne.fr>
References: <Your message of Tue, 27 Mar 2001 14:43:42 +0300. <3AC07CEE.BC5DF2C0@lmf.ericsson.se>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XA5N92>; Tue, 27 Mar 2001 17:14:26 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCD5@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W20LWB>; Tue, 27 Mar 2001 17:21:39 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCD6@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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: <Roam.SIMC.2.0.6.985706086.9959.pcalhoun@nasnfs>
References: <15040.44291.238997.780414@thomasm-u1.cisco.com>
	<Roam.SIMC.2.0.6.985706086.9959.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XA5307>; Tue, 27 Mar 2001 17:51:50 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCD8@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <paul@francis.com>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Mar 2001 08:45:42 -0800 (PST)
Date: Tue, 27 Mar 2001 08:45:38 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
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: <Roam.SIMC.2.0.6.985711538.2929.pcalhoun@nasnfs>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <behcet.sarikaya@usa.alcatel.com>
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'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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: <Roam.SIMC.2.0.6.985711538.2929.pcalhoun@nasnfs>
References: <15040.47810.150384.99403@thomasm-u1.cisco.com>
	<Roam.SIMC.2.0.6.985711538.2929.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <charliep@iprg.nokia.com>
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 <paul@francis.com>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
References: <Roam.SIMC.2.0.6.985643757.13603.pcalhoun@nasnfs> <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Samita.Chakrabarti@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Samita.Chakrabarti@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <paul@francis.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <15040.44291.238997.780414@thomasm-u1.cisco.com><Roam.SIMC.2.0.6.985706086.9959.pcalhoun@nasnfs> <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <paul@francis.com>
To: <mobile-ip@sunroof.eng.sun.com>, "Thomas Narten" <narten@raleigh.ibm.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <sjj0@gte.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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>
	<Roam.SIMC.2.0.6.985706086.9959.pcalhoun@nasnfs>
	<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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <H3HY1VS1>; Tue, 27 Mar 2001 14:21:25 -0600
Message-ID: <9A9367D1556AD21182C40000F80930AB025E56CD@crchy28b.us.nortel.com>
From: "Mohamed Khalil" <mkhalil@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>length field</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>All,</FONT>
</P>

<P><FONT SIZE=3D2>to remove the confusion of interpreting the meaning =
of the length field in MIER and GNAI, we will change the definition =
slightly&nbsp; as follows:</FONT></P>

<P><FONT SIZE=3D2>MIER:</FONT>
</P>

<P><FONT SIZE=3D2>Length </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; 8-bit unsigned integer. Length of the =
extension, in octets,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; excluding the extension Type and the =
extension Length fields.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; This field MUST be set to 1 plus the =
total length of the data field.</FONT>
</P>

<P><FONT SIZE=3D2>GNAI:</FONT>
</P>

<P><FONT SIZE=3D2>Length</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; 8-bit unsigned integer. Length of the =
extension, in octets,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; excluding the extension Type and the =
extension Length fields.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; This field MUST be set to 1 plus the =
total length of the NAI field.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>MK</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&nbsp;&nbsp; </FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
To: mobile-ip@sunroof.eng.sun.com
Cc: Pekka Nikander <pekka.nikander@nomadiclab.com>
In-Reply-To: "Your message with ID" <200103270939.f2R9ddA76136@givry.rennes.enst-bretagne.fr>
Message-ID: <Roam.SIMC.2.0.6.985727186.13789.nordmark@bebop.france>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <paul@francis.com>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XA5S7Z>; Tue, 27 Mar 2001 23:51:37 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCDC@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'James Kempf'" <kempf@heliopolis.eng.sun.com>,
        Samita.Chakrabarti@eng.sun.com, mobile-ip@sunroof.eng.sun.com
Cc: claude.castelluccia@inria.fr,
        "Karim El-Malki (ERA)"
	 <Karim.El-Malki@era.ericsson.se>,
        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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XA5TAD>; Wed, 28 Mar 2001 00:08:26 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCDD@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'Samita Chakrabarti'" <Samita.Chakrabarti@eng.sun.com>,
        mobile-ip@sunroof.eng.sun.com
Cc: "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>,
        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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W20Q45>; Wed, 28 Mar 2001 00:14:08 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCDE@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'James Kempf'" <kempf@heliopolis.eng.sun.com>,
        Samita.Chakrabarti@eng.sun.com, mobile-ip@sunroof.eng.sun.com
Cc: claude.castelluccia@inria.fr,
        "Karim El-Malki (ERA)"
	 <Karim.El-Malki@era.ericsson.se>,
        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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9W20QW5>; Wed, 28 Mar 2001 00:20:56 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCDF@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <paul@francis.com>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <eanderlind@lucent.com>
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: <Roam.SIMC.2.0.6.985727186.13789.nordmark@bebop.france>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Jari.Arkko@lmf.ericsson.se>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Mar 2001 22:53:25 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2S6rOE32697
	for <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <jmalinen@iprg.nokia.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <claude.castelluccia@inrialpes.fr>
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hesham Soliman (ERA)" <Hesham.Soliman@era.ericsson.se>
CC: "'James Kempf'" <kempf@heliopolis.eng.sun.com>,
        Samita.Chakrabarti@eng.sun.com, mobile-ip@sunroof.eng.sun.com,
        claude.castelluccia@inria.fr,
        "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>,
        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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
"Hesham Soliman (ERA)" wrote:
<blockquote TYPE=CITE>James,
<p>One other thing I forgot to mention is that whether
<br>you tunnel or not, the header will change every time
<br>the MN moves. Unless we assume a MIPv4 model.
<p>Hesham
<br>&nbsp;</blockquote>
Hello,
<p>I think what James is saying is that header compression
<br>will be difficult for MIPv6...i.e. no packets will be compressed
<br>... it is better not using tunnels...
<br>Am I right James?
<p>I am not completly convinced about this arguments and I am sure that
<br>the RoHc will eventually find a solution...
<p>However if we assume that this problem will not be solved, I think that
I would
<br>make more sense to have the wireless access routers decapsulate the
packets coming
<br>from the MAP and forward them on the air link... these packets could
then be compressed
<br>because the destination address does not change (the destination is
the RCoA) as long as the MN
<br>is supported by the same MAP (i.e. the RCoA does not change).
<p>This requires to modify the wireless access routers but you gain even
more than the proposed 3rd mode
<br>in term of bandwidth comsumption because header compression is then
possible on the air link....
<p>Comments?
<p>thanks,
<p>Claude.
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <HYPNZ7HQ>; 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 <jeanmichel.combes@rd.francetelecom.fr>
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 <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <HYPNZ7NQ>; 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 <jeanmichel.combes@rd.francetelecom.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XA6MZ0>; Wed, 28 Mar 2001 14:08:40 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCE1@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'James Kempf'" <kempf@heliopolis.eng.sun.com>, micke@sm.luth.se,
        cabo@tzi.org
Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se,
        "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Mar 2001 05:32:44 -0800 (PST)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id <HQBRM61Z>; Wed, 28 Mar 2001 08:27:41 -0500
Message-ID: <CD8355C7E19ED411BD5F00508BB0D19D1C55D6@mail.megisto.com>
From: Phil Roberts <PRoberts@MEGISTO.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>length field</TITLE>

<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Mohamed Khalil 
  [mailto:mkhalil@nortelnetworks.com]<BR><B>Sent:</B> Tuesday, March 27, 2001 
  3:21 PM<BR><B>To:</B> 'mobile-ip@sunroof.eng.sun.com'<BR><B>Subject:</B> 
  [mobile-ip] length field<BR><BR></FONT></DIV>
  <P><FONT size=2>All,</FONT> </P>
  <P><FONT size=2>to remove the confusion of interpreting the meaning of the 
  length field in MIER and GNAI, we will change the definition slightly&nbsp; as 
  follows:</FONT></P>
  <P><FONT size=2>MIER:</FONT> </P>
  <P><FONT size=2>Length </FONT><BR><FONT size=2>&nbsp;</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp; 8-bit unsigned integer. Length of the extension, in 
  octets,</FONT> <BR><FONT size=2>&nbsp;&nbsp; excluding the extension Type and 
  the extension Length fields.</FONT> <BR><FONT size=2>&nbsp;&nbsp; This field 
  MUST be set to 1 plus the total length of the data field.</FONT> <BR><SPAN 
  class=681003113-28032001><FONT face=Arial color=#0000ff size=2>[Phil 
  Roberts]&nbsp;</FONT></SPAN></P>
  <P><SPAN class=681003113-28032001><FONT face=Arial color=#0000ff size=2>I'm 
  assuming this is the Length field for the short extension 
  only?</FONT></SPAN></P>
  <P><SPAN class=681003113-28032001></SPAN>&nbsp;</P>
  <P><SPAN class=681003113-28032001>&nbsp;</SPAN></P>
  <P><FONT size=2>GNAI:</FONT> </P>
  <P><FONT size=2>Length</FONT> </P>
  <P><FONT size=2>&nbsp;&nbsp; 8-bit unsigned integer. Length of the extension, 
  in octets,</FONT> <BR><FONT size=2>&nbsp;&nbsp; excluding the extension Type 
  and the extension Length fields.</FONT> <BR><FONT size=2>&nbsp;&nbsp; This 
  field MUST be set to 1 plus the total length of the NAI field.</FONT> 
  </P><BR><BR>
  <P><FONT size=2>MK</FONT> </P><BR><BR>
  <P><FONT size=2>&nbsp;&nbsp; </FONT></P><BR><BR></BLOCKQUOTE></BODY></HTML>

------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <H3HYF1BA>; Wed, 28 Mar 2001 09:10:43 -0600
Message-ID: <9A9367D1556AD21182C40000F80930AB025E56D3@crchy28b.us.nortel.com>
From: "Mohamed Khalil" <mkhalil@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <mkhalil@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>length field</TITLE>

<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Phil Roberts 
  [mailto:PRoberts@MEGISTO.com]<BR><B>Sent:</B> Wednesday, March 28, 2001 7:28 
  AM<BR><B>To:</B> 'mobile-ip@sunroof.eng.sun.com'<BR><B>Subject:</B> RE: 
  [mobile-ip] length field<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
  <BLOCKQUOTE 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Mohamed Khalil 
    [mailto:mkhalil@nortelnetworks.com]<BR><B>Sent:</B> Tuesday, March 27, 2001 
    3:21 PM<BR><B>To:</B> 'mobile-ip@sunroof.eng.sun.com'<BR><B>Subject:</B> 
    [mobile-ip] length field<BR><BR></FONT></DIV>
    <P><FONT size=2>All,</FONT> </P>
    <P><FONT size=2>to remove the confusion of interpreting the meaning of the 
    length field in MIER and GNAI, we will change the definition slightly&nbsp; 
    as follows:</FONT></P>
    <P><FONT size=2>MIER:</FONT> </P>
    <P><FONT size=2>Length </FONT><BR><FONT size=2>&nbsp;</FONT> <BR><FONT 
    size=2>&nbsp;&nbsp; 8-bit unsigned integer. Length of the extension, in 
    octets,</FONT> <BR><FONT size=2>&nbsp;&nbsp; excluding the extension Type 
    and the extension Length fields.</FONT> <BR><FONT size=2>&nbsp;&nbsp; This 
    field MUST be set to 1 plus the total length of the data field.</FONT> 
    <BR><SPAN class=681003113-28032001><FONT face=Arial color=#0000ff 
    size=2>[Phil Roberts]&nbsp;</FONT></SPAN></P>
    <P><SPAN class=681003113-28032001><FONT face=Arial><FONT color=#0000ff><FONT 
    size=2>I'm assuming this is the Length field for the short extension 
    only?<BR></FONT></FONT></FONT></SPAN><SPAN class=681003113-28032001><FONT 
    face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
    class=037440715-28032001>&nbsp;</P>
    <DIV><SPAN class=037440715-28032001><FONT face=Arial color=#0000ff 
    size=2>MK&gt; yes</FONT></SPAN></DIV></SPAN></FONT></FONT></FONT></SPAN>
    <P><SPAN class=681003113-28032001></SPAN>&nbsp;</P>
    <P><SPAN class=681003113-28032001></SPAN>&nbsp;</P>
    <P><FONT size=2>GNAI:</FONT> </P>
    <P><FONT size=2>Length</FONT> </P>
    <P><FONT size=2>&nbsp;&nbsp; 8-bit unsigned integer. Length of the 
    extension, in octets,</FONT> <BR><FONT size=2>&nbsp;&nbsp; excluding the 
    extension Type and the extension Length fields.</FONT> <BR><FONT 
    size=2>&nbsp;&nbsp; This field MUST be set to 1 plus the total length of the 
    NAI field.</FONT> </P><BR><BR>
    <P><FONT size=2>MK</FONT> </P><BR><BR>
    <P><FONT size=2>&nbsp;&nbsp; 
</FONT></P><BR><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <paul@francis.com>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <paul@francis.com>
To: <mobile-ip@sunroof.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Mar 2001 11:02:38 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2SJ2aJ24868
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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'" <Samita.Chakrabarti@eng.sun.com>,
        "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>,
        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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9WJAZNT>; Wed, 28 Mar 2001 21:57:42 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCEE@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'James Kempf'" <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9WJAZ37>; Wed, 28 Mar 2001 22:02:01 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCEF@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9WJAZ5X>; Wed, 28 Mar 2001 22:50:30 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCF2@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>,
        "'James Kempf'" <kempf@heliopolis.eng.sun.com>, 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9WJA5BC>; Wed, 28 Mar 2001 23:19:06 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCF3@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T52924db340ac12f256079@davir03nok.americas.nokia.com>;
 Wed, 28 Mar 2001 15:38:03 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <GKQMGZ03>; Wed, 28 Mar 2001 15:38:03 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4601A659CA@bseis01nok>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XA6750>; Wed, 28 Mar 2001 23:37:12 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCF4@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Mar 2001 13:52:57 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2SLqrM12277
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Mar 2001 14:28:23 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2SMSJH17018
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <miyashita@horse.mes.titech.ac.jp>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Mar 2001 18:35:59 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2T2ZuX10940
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Mar 2001 18:47:45 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2T2lii07356
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Theo Pagtzis wrote:
<blockquote TYPE=CITE>Claude/Hesham,
<p>&nbsp;&nbsp; why in Basic mode you want to keep the Home addr secret
from the MAP.
<br>What good would it do???
<br>&nbsp;</blockquote>
Hello Theo,
<p>We actually don't intend to hide the Home Address from the MAP this
is just
<br>the way it is... The MAP is a HomeAgent that binds the RCoA to the
LCoA...
<br>From the MAP perspective the RCoA&nbsp;is the home address and the
LCoA the CoA...
<br>The MAP&nbsp;is a HomeAgent..it does not even know that it is used
by HMIPv6 ....
<p>regards,
<p>Claude.
<br>&nbsp;
<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Hello Zhigang,
<p>I seems from your email that context relocation will be very useful
for RoHC.
<br>Is istalso the case if some packets are lost&nbsp; when a MN moves
from one base station
<br>to another one?
<p>In this case it is better to restart the context or relocate it?
<br>Do you know of any studies on this topic?
<p>thanks a lot!
<p>Claude.
<p>zhigang.liu@nokia.com wrote:
<blockquote TYPE=CITE>Hi,
<br>&nbsp;
<br>&nbsp;
<p>There are some guessing/assumptions behind the number (3-4).
<br>I'm not so sure that's always the case. The radio link condition
<br>before/after handover is likely be worse than normal condition.
<br>That may mean more packets could be lost (in this case, IR packets).
<br>That will has impacts on the guessing of the number.
<p>Although we're talking about "very few" packets (be it 3-4 or 5-6),
<br>they are LARGE (40+ bytes for RTP/UDP/IPv4 headers and 60+ bytes
<br>for RTP/UDP/IPv6 headers). And most of the header fields are static.
<br>That is the issue. With HC context relocation, there is no need to
<br>send the static fields over the air. The reduced overhead means
<br>less pain (e.g. delay, possible stealing or blanking of voice payload).
<p>Note that smaller packets have lower chance to be hit by transmission
<br>errors (even just one bit) and thus lost, assuming no link layer
<br>retransmission (which makes sense for real-time multimedia).
<br>&nbsp;</blockquote>

<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <HZY8LFR5>; Wed, 28 Mar 2001 08:33:36 +0200
Message-ID: <91A311FF6A85D3118DDF0060080C3D82010DCD18@lat3721.rd.francetelecom.fr>
From: KASSI-LAHLOU Mohammed FTRD/DMI/CAE
	 <mohamed.kassilahlou@rd.francetelecom.fr>
To: "'Pekka Nikander'" <pekka.nikander@nomadiclab.com>,
        KASSI-LAHLOU Mohammed FTRD/DMI/CAE
	 <mohamed.kassilahlou@rd.francetelecom.fr>
Cc: mobile-ip@sunroof.eng.sun.com,
        Claude Castelluccia
	 <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9WJB8HA>; Thu, 29 Mar 2001 16:52:47 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCF7@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9WJB9V5>; Thu, 29 Mar 2001 17:33:27 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCF8@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Mar 2001 07:54:49 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2TFskU17973
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Mar 2001 08:15:24 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2TGFOk19116
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9WJCANP>; Thu, 29 Mar 2001 18:49:05 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCFD@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XA8DXJ>; Thu, 29 Mar 2001 18:58:31 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCFE@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'zhigang.liu@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 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T5296b379a9ac12f254079@davir01nok.americas.nokia.com>;
 Thu, 29 Mar 2001 12:07:42 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <GKQMHDYV>; Thu, 29 Mar 2001 12:07:42 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4601A659CF@bseis01nok>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T5296d6d24cac12f257079@davir04nok.americas.nokia.com>;
 Thu, 29 Mar 2001 12:46:19 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <GKS5J0FZ>; Thu, 29 Mar 2001 12:46:19 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4601A659D0@bseis01nok>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9WJCB9Q>; Thu, 29 Mar 2001 21:00:04 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD01@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'rajeev.koodli@nokia.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T5297084ec5ac12f255079@davir02nok.americas.nokia.com>;
 Thu, 29 Mar 2001 13:40:22 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <GKS5KA1D>; Thu, 29 Mar 2001 13:40:22 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4601A659D4@bseis01nok>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Mar 2001 11:59:48 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2TJxin03482
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Mar 2001 13:07:54 -0800 (PST)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id <HQBRM7ZZ>; Thu, 29 Mar 2001 16:02:48 -0500
Message-ID: <CD8355C7E19ED411BD5F00508BB0D19D1C5616@mail.megisto.com>
From: Phil Roberts <PRoberts@MEGISTO.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Samita.Chakrabarti@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <hchaskar@hotmail.com>
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: <F863EU2Sn9skdVwlc6z00010929@hotmail.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <gab@Sun.COM>
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: <F863EU2Sn9skdVwlc6z00010929@hotmail.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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <H6KSYDAM>; Thu, 29 Mar 2001 16:42:42 -0600
Message-ID: <FB4781AB3309D5118DCD00508BF93CA22D8CB8@zrc2c001.us.nortel.com>
From: "Haseeb Akhtar" <haseeb@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] QoS Work Item</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Phil,</FONT>
</P>

<P><FONT SIZE=2>It is obvious from the long email exchanges that we have seen </FONT>
<BR><FONT SIZE=2>before the IETF week that the QoS groups, at least as it </FONT>
<BR><FONT SIZE=2>exists today, may not necessarily cater to the problems/perspectives</FONT>
<BR><FONT SIZE=2>that are germane to mobility. </FONT>
</P>

<P><FONT SIZE=2>Having said that, I also believe we should utilize the rich </FONT>
<BR><FONT SIZE=2>experiences of the intserv/diffserv/RSVP folks.</FONT>
</P>

<P><FONT SIZE=2>I propose this group comes up with the requirements and then form</FONT>
<BR><FONT SIZE=2>a design team (that comprises of the both sides - QoS groups and us) </FONT>
<BR><FONT SIZE=2>to come up with a solution.</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
</P>

<P><FONT SIZE=2>Haseeb</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Phil Roberts [<A HREF="mailto:PRoberts@MEGISTO.com">mailto:PRoberts@MEGISTO.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, March 29, 2001 3:03 PM</FONT>
<BR><FONT SIZE=2>To: 'mobile-ip@sunroof.eng.sun.com'</FONT>
<BR><FONT SIZE=2>Subject: [mobile-ip] QoS Work Item</FONT>
</P>
<BR>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>We have a charter item to consider the relationship between MIP and</FONT>
<BR><FONT SIZE=2>QoS.&nbsp; That's pretty vague.&nbsp; We've seen a couple of drafts on this, and</FONT>
<BR><FONT SIZE=2>actually have a request to make one a working group item.&nbsp; This is</FONT>
<BR><FONT SIZE=2>premature.&nbsp; The working group needs to consider what exactly we need to do.</FONT>
</P>

<P><FONT SIZE=2>Our charter says:&nbsp; &quot;In the longer term, the WG needs to address: </FONT>
<BR><FONT SIZE=2>- QoS in the mobile IP environment using diff-serv and/or int-serv/RSVP.&quot; </FONT>
</P>

<P><FONT SIZE=2>The problem is that MNs may be using QoS mechanisms on their flows and these</FONT>
<BR><FONT SIZE=2>MNs will sometimes move using MIP mechanisms.&nbsp; We have some options to</FONT>
<BR><FONT SIZE=2>explore about how to address this.&nbsp; We could address QoS issues related</FONT>
<BR><FONT SIZE=2>specifically to mobile IP in this WG based on QoS work done in other WGs</FONT>
<BR><FONT SIZE=2>(DiffServ, IntServ).&nbsp; We could just provide requirements from a MIP</FONT>
<BR><FONT SIZE=2>perspective to WGs working on these QoS mechanisms and ask them to solve it.</FONT>
<BR><FONT SIZE=2>We could work jointly with folks in other working groups to produce some</FONT>
<BR><FONT SIZE=2>proposals about how to proceed.&nbsp; It is clear we don't have the option to</FONT>
<BR><FONT SIZE=2>invent another QoS protocol and we shouldn't be doing this work in</FONT>
<BR><FONT SIZE=2>isolation.</FONT>
</P>

<P><FONT SIZE=2>So, we'd like to know the working group's opinion on the direction we take.</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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" <cabo@tzi.org>
Cc: "Michael Thomas" <mat@cisco.com>, <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
In-Reply-To: <NEBBJFHFCKHKFCNLJJBPKEKBEOAA.cabo@tzi.org>
References: <15043.34717.849084.517703@thomasm-u1.cisco.com>
	<NEBBJFHFCKHKFCNLJJBPKEKBEOAA.cabo@tzi.org>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <AA15275>; 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 <mankin@isi.edu>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Mar 2001 18:02:09 -0500 (EST)
From: "Andrew T. Campbell" <campbell@comet.columbia.edu>
To: <mobile-ip@sunroof.eng.sun.com>
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: <F863EU2Sn9skdVwlc6z00010929@hotmail.com>
Importance: Normal
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T5297cd12b4ac12f257079@davir04nok.americas.nokia.com>;
 Thu, 29 Mar 2001 17:15:17 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <GKQMHJ1Q>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <AA15303>; 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 <mankin@isi.edu>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9WJC1BD>; Fri, 30 Mar 2001 01:37:44 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD03@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T5297e40900ac12f254079@davir01nok.americas.nokia.com>;
 Thu, 29 Mar 2001 17:40:22 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <GKQMHJNF>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Erik.Nordmark@eng.sun.com>
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" <B9CFA6CE8FFDD211A1FB0008C7894E4601A659D0@bseis01nok>
Message-ID: <Roam.SIMC.2.0.6.985910070.6534.nordmark@bebop.france>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Mar 2001 16:09:40 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2U09bc24982
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9WJC1MR>; Fri, 30 Mar 2001 02:14:12 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD04@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <kempf@heliopolis.eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XA8H4G>; Fri, 30 Mar 2001 02:26:50 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD05@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XA8HYR>; Fri, 30 Mar 2001 02:48:13 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD06@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T52982aa56dac12f254079@davir01nok.americas.nokia.com>;
 Thu, 29 Mar 2001 18:57:29 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <GKQMHKDZ>; Thu, 29 Mar 2001 18:57:29 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4601A659D6@bseis01nok>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <rajeev@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Dr. Carsten Bormann" <cabo@tzi.org>
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: <NEBBJFHFCKHKFCNLJJBPAEKBEOAA.cabo@tzi.org>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T52984df7b0ac12f257079@davir04nok.americas.nokia.com>;
 Thu, 29 Mar 2001 19:36:04 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <GKS5K18R>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Mar 2001 18:13:45 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2U2Dfu16031
	for <mobile-ip@sunroof.eng.sun.com>; 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" <TJ@Kniveton.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <claude.castelluccia@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
James Kempf wrote:
<blockquote TYPE=CITE>&nbsp;We don't have to be involved in the
<br>details, but we at least have to know:
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1) That either header compression
can restart fast
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; or with context transfer
and updating of the context using
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the new CoA.
<br>&nbsp;</blockquote>
just a quick comment:&nbsp;in HMIPv6 basic mode, the MN&nbsp;uses the RCoA
as source address ...this address
<br>only changes when the MN&nbsp;moves from one MAP&nbsp;to another...
<p>HMIPv6 might actually make things easier than MIPv6 concerning header
compression....
<p>regards,
<p>Claude.
<br>&nbsp;
<blockquote TYPE=CITE>&nbsp;</blockquote>

<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <thierry.ernst@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <thierry.ernst@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <P1>
	- int1 points to a link internal to the mobile network and has prefix
<P2>
	
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 <P2>: 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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <FSJNV21N>; Fri, 30 Mar 2001 14:34:11 +0200
Message-ID: <EB2D9281A815D31181DA0001FA7E2E187F4F72@mchh157e.mch.pn.siemens.de>
From: Erdmann Antonius  ICM N MC MI E 3 <Antonius.Erdmann@icn.siemens.de>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <schfeld@darmstadt.gmd.de>
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: <EB2D9281A815D31181DA0001FA7E2E187F4F72@mchh157e.mch.pn.siemens.de>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <peter.grimstrup@ted.ericsson.dk>
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: <EB2D9281A815D31181DA0001FA7E2E187F4F72@mchh157e.mch.pn.siemens.de>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <hchaskar@hotmail.com>
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: <F302VApwOLZCHusMjQH0001213e@hotmail.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Yes we did intimate some of these requirements in NSIS BOF at IETF 50 (we 
had only 3 minutes though :-(.

>From: gabriel montenegro <gab@Sun.COM>
>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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <hchaskar@hotmail.com>
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: <F165SgcOrBLSAQV6uPD00010de1@hotmail.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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" <campbell@comet.columbia.edu>
>Reply-To: mobile-ip@sunroof.eng.sun.com
>To: <mobile-ip@sunroof.eng.sun.com>
>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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mattias.pettersson@era.ericsson.se>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <P1>
>         - int1 points to a link internal to the mobile network and has prefix
> <P2>
> 
> 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 <P2>: 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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <fred@cisco.com>
Subject: RE: [mobile-ip] QoS Work Item
Cc: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
In-Reply-To: <FB4781AB3309D5118DCD00508BF93CA22D8CB8@zrc2c001.us.nortel.
 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T529b727fbdac12f256079@davir03nok.americas.nokia.com>;
 Fri, 30 Mar 2001 10:14:50 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <H8771NL3>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T529b644192ac12f255079@davir02nok.americas.nokia.com>;
 Fri, 30 Mar 2001 09:59:17 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <H88RY198>; 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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <G9XA9NGW>; Fri, 30 Mar 2001 18:44:28 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD07@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Mar 2001 09:23:36 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2UHNXY14075
	for <mobile-ip@sunroof.eng.sun.com>; 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 <t.pagtzis@cs.ucl.ac.uk>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Mar 2001 09:52:16 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2UHqD017271
	for <mobile-ip@sunroof.eng.sun.com>; 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 <rajeev@iprg.nokia.com>
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: <F863EU2Sn9skdVwlc6z00010929@hotmail.com> <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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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: <F863EU2Sn9skdVwlc6z00010929@hotmail.com>
	<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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Samita.Chakrabarti@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <thierry.ernst@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <thierry.ernst@inrialpes.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <hchaskar@hotmail.com>
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: <F180KtzcbLDiKBsuZ2K00011ea2@hotmail.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
>From: Michael Thomas <mat@cisco.com>
>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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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: <F180KtzcbLDiKBsuZ2K00011ea2@hotmail.com>
References: <F180KtzcbLDiKBsuZ2K00011ea2@hotmail.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Mar 2001 14:04:29 -0800 (PST)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2UM4Rp31320
	for <mobile-ip@sunroof.eng.sun.com>; 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 <rajeev@iprg.nokia.com>
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: <F180KtzcbLDiKBsuZ2K00011ea2@hotmail.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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <TJ@Kniveton.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mattias.pettersson@era.ericsson.se>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mat@cisco.com>
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/AuzN4m<D]vnFJ>u!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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mattias.pettersson@era.ericsson.se>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mattias.pettersson@era.ericsson.se>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <T529ced9e99ac12f254079@davir01nok.americas.nokia.com>;
 Fri, 30 Mar 2001 17:08:56 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <H8771431>; Fri, 30 Mar 2001 17:08:56 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4601A659E1@bseis01nok>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Mohan.Parthasarathy@eng.sun.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
cc: Pekka Nikander <pekka.nikander@nomadiclab.com>
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.
             <Roam.SIMC.2.0.6.985727186.13789.nordmark@bebop.france> 
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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" <TJ@Kniveton.com>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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 <mobileip-archive@odin.ietf.org>; 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 <mobile-ip-dist@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <mobile-ip@sunroof.eng.sun.com>; 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 <Francis.Dupont@enst-bretagne.fr>
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: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=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