From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov  1 20:30:51 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28340
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Nov 2000 20:30:51 -0500 (EST)
Received: from standards (47.234.32.16:4983) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE4A1@standards.nortelnetworks.com>; Wed, 1 Nov 2000 20:12:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 67175 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 20:12:45 -0500
Received: from flower.comeng.chungnam.ac.kr by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBAE49F@standards.nortelnetworks.com>; Wed, 1 Nov 2000 20:12:44
          -0500
Received: from Beethoven (Beethoven.comeng.chungnam.ac.kr [168.188.46.199]) by
          flower.comeng.chungnam.ac.kr (8.9.1/8.9.1) with SMTP id IAA10466 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 2 Nov 2000 08:40:09
          +0900 (KST)
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.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Approved-By:  "Park, Hyun Seo" <hspark@CE.CNU.AC.KR>
Message-ID:  <00a601c0445d$d6c11800$c72ebca8@ce.cnu.ac.kr>
Date:         Thu, 2 Nov 2000 08:45:28 +0900
Reply-To: "Park, Hyun Seo" <hspark@ce.cnu.ac.kr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Park, Hyun Seo" <hspark@ce.cnu.ac.kr>
Subject:      [MOBILE-IP] Question about "Route Optimization in Mobile IP"
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id UAA28340

Hello, All ....
I have a question about "Route Optimization in Mobile IP" ...

When MN comes back Home Network, it does "Deregistration" with its HA ...
MN sends "Registration Request" with <COA = MN's Home Address> to HA ...

MN can include "Previous FA Notification Extension", if possible,
    Then, HA sends "Binding Update" to MN's previous FA .. 
    Binding Update : <COA = MN's Home Address,  Lifetime = 0>

    The old FA receives that "Binding Update", 
    then it deletes visitor list entry for that MN ....
    And it does not make "Binding Cache" for that MN 
    because <COA = MN's Home Address, Lifetime = 0>...

Now, Suppose a CN that has "Binding Cache" <COA = MN's old FA> ...
When it sends datagrams to MN, it tunnels them to MN's old FA ...
Then MN's old FA decapsulates them 
    and re-routes (not tunnels) them to MN's Home Network ...
MN's old FA does not send "Binding Warning" to HA because it has no "Binding Cache"...
And CN can not receive "Binding Update" from HA ... 
So, CN will countinuously tunnel datagrams until it expires "Binding Cache" for MN ..

Am I right ? 
Any comments will be appreciated ... 
Thanks in advance ...          

--------------------------------------
Park, Hyun Seo 
Graduate Student
Department of Computer Engineering, Chungnam National University
220 Gung-dong,YuSeong-Gu, Taejon, 305764, Korea
E-mail: hspark@ce.cnu.ac.kr
ICQ # : 28055093   
Phone : +82-42-823-6049








From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  2 01:00:04 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05767
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Nov 2000 01:00:04 -0500 (EST)
Received: from standards (47.234.32.16:3416) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE587@standards.nortelnetworks.com>; Thu, 2 Nov 2000 0:42:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 67473 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 00:42:11 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBAE585@standards.nortelnetworks.com>; Thu, 2 Nov 2000 0:42:10
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id VAA25146;
          Wed, 1 Nov 2000 21:58:05 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA25w1t10787; Wed, 1 Nov 2000 21:58:01
          -0800
X-Virus-Scanned:  Wed, 1 Nov 2000 21:58:01 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from Icharliep-1.iprg.nokia.com (205.226.22.18,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdc5F5DF; Wed, 01 Nov 2000
          21:57:49 PST
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <00a601c0445d$d6c11800$c72ebca8@ce.cnu.ac.kr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Charlie Perkins <charliep@IPRG.NOKIA.COM>
Message-ID:  <3A010205.D5D2D68D@iprg.nokia.com>
Date:         Wed, 1 Nov 2000 21:56:21 -0800
Reply-To: Charlie Perkins <charliep@iprg.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Charlie Perkins <charliep@iprg.nokia.com>
Organization: Nokia
Subject:      Re: [MOBILE-IP] Question about "Route Optimization in Mobile IP"
X-To:         "Park, Hyun Seo" <hspark@ce.cnu.ac.kr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello,

Yes, I think you are correct.  In the past, the foreign agent had
been allowed to send a Binding Warning to the correspondent
node.  I thought that it still could do so, but upon re-reading the
specification I see that it isn't in there now.  We could say that
the foreign agent SHOULD send a Binding Warning to the
correspondent node, if the foreign agent does not have any
record of the home agent for the mobile node.  The correspondent
node presumably will understand the message, since it's stale
binding for the mobile node was produced by processing a
previous  Binding Update in the first place.

Does this solve the problem?

Regards,
Charlie P.


"Park, Hyun Seo" wrote:

> Hello, All ....
> I have a question about "Route Optimization in Mobile IP" ...
>
> When MN comes back Home Network, it does "Deregistration" with its HA ...
> MN sends "Registration Request" with <COA = MN's Home Address> to HA ...
>
> MN can include "Previous FA Notification Extension", if possible,
>     Then, HA sends "Binding Update" to MN's previous FA ..
>     Binding Update : <COA = MN's Home Address,  Lifetime = 0>
>
>     The old FA receives that "Binding Update",
>     then it deletes visitor list entry for that MN ....
>     And it does not make "Binding Cache" for that MN
>     because <COA = MN's Home Address, Lifetime = 0>...
>
> Now, Suppose a CN that has "Binding Cache" <COA = MN's old FA> ...
> When it sends datagrams to MN, it tunnels them to MN's old FA ...
> Then MN's old FA decapsulates them
>     and re-routes (not tunnels) them to MN's Home Network ...
> MN's old FA does not send "Binding Warning" to HA because it has no "Binding Cache"...
> And CN can not receive "Binding Update" from HA ...
> So, CN will countinuously tunnel datagrams until it expires "Binding Cache" for MN ..
>
> Am I right ?
> Any comments will be appreciated ...
> Thanks in advance ...
>
> --------------------------------------
> Park, Hyun Seo
> Graduate Student
> Department of Computer Engineering, Chungnam National University
> 220 Gung-dong,YuSeong-Gu, Taejon, 305764, Korea
> E-mail: hspark@ce.cnu.ac.kr
> ICQ # : 28055093
> Phone : +82-42-823-6049


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  2 01:36:15 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26778
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Nov 2000 01:36:14 -0500 (EST)
Received: from standards (47.234.32.16:3416) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE5E5@standards.nortelnetworks.com>; Thu, 2 Nov 2000 1:18:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 67599 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 01:18:23 -0500
Received: from flower.comeng.chungnam.ac.kr by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBAE5E3@standards.nortelnetworks.com>; Thu, 2 Nov 2000 1:18:08
          -0500
Received: from Beethoven (Beethoven.comeng.chungnam.ac.kr [168.188.46.199]) by
          flower.comeng.chungnam.ac.kr (8.9.1/8.9.1) with SMTP id PAA17706 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 2 Nov 2000 15:28:33
          +0900 (KST)
References: <00a601c0445d$d6c11800$c72ebca8@ce.cnu.ac.kr> 
            <3A010205.D5D2D68D@iprg.nokia.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_003D_01C044E2.4D9CE740"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Approved-By:  "Park, Hyun Seo" <hspark@CE.CNU.AC.KR>
Message-ID:  <004001c04496$de125360$c72ebca8@ce.cnu.ac.kr>
Date:         Thu, 2 Nov 2000 15:33:52 +0900
Reply-To: "Park, Hyun Seo" <hspark@ce.cnu.ac.kr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Park, Hyun Seo" <hspark@ce.cnu.ac.kr>
Subject:      Re: [MOBILE-IP] Question about "Route Optimization in Mobile IP"
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_003D_01C044E2.4D9CE740
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: base64

VGhhbmtzLCBDaGFybGllIC4uLiANCk15IGNvbW1lbnRzIGFyZSBiZWxvdyAuLi4uDQoNCj4gSGVs
bG8sDQo+IA0KPiBZZXMsIEkgdGhpbmsgeW91IGFyZSBjb3JyZWN0LiAgSW4gdGhlIHBhc3QsIHRo
ZSBmb3JlaWduIGFnZW50IGhhZA0KPiBiZWVuIGFsbG93ZWQgdG8gc2VuZCBhIEJpbmRpbmcgV2Fy
bmluZyB0byB0aGUgY29ycmVzcG9uZGVudA0KPiBub2RlLiAgSSB0aG91Z2h0IHRoYXQgaXQgc3Rp
bGwgY291bGQgZG8gc28sIGJ1dCB1cG9uIHJlLXJlYWRpbmcgdGhlDQo+IHNwZWNpZmljYXRpb24g
SSBzZWUgdGhhdCBpdCBpc24ndCBpbiB0aGVyZSBub3cuICBXZSBjb3VsZCBzYXkgdGhhdA0KPiB0
aGUgZm9yZWlnbiBhZ2VudCBTSE9VTEQgc2VuZCBhIEJpbmRpbmcgV2FybmluZyB0byB0aGUNCj4g
Y29ycmVzcG9uZGVudCBub2RlLCBpZiB0aGUgZm9yZWlnbiBhZ2VudCBkb2VzIG5vdCBoYXZlIGFu
eQ0KPiByZWNvcmQgb2YgdGhlIGhvbWUgYWdlbnQgZm9yIHRoZSBtb2JpbGUgbm9kZS4gIA0KDQpb
UGFya10gSSB0aGluayBGQSBzZW5kcyBhICJCaW5kaW5nIFdhcm5pbmciIHRvIG5vdCBDTiBidXQg
SEEgLi4uDQogICAgQW0gSSBjb3JyZWN0ID8gIA0KDQo+IFRoZSBjb3JyZXNwb25kZW50IG5vZGUg
cHJlc3VtYWJseSB3aWxsIHVuZGVyc3RhbmQgdGhlIG1lc3NhZ2UsIA0KPiBzaW5jZSBpdCdzIHN0
YWxlIGJpbmRpbmcgZm9yIHRoZSBtb2JpbGUgbm9kZSB3YXMgcHJvZHVjZWQgYnkgcHJvY2Vzc2lu
ZyBhDQo+IHByZXZpb3VzICBCaW5kaW5nIFVwZGF0ZSBpbiB0aGUgZmlyc3QgcGxhY2UuDQo+IA0K
PiBEb2VzIHRoaXMgc29sdmUgdGhlIHByb2JsZW0/DQoNCltQYXJrXSBIb3cgYWJvdXQgIkJpbmRp
bmcgQ2FjaGUgZm9yIERlcmVnaXN0ZXJlZCBNTiIgPw0KICAgIFdoZW4gYW55IG5vZGUgcmVjZWl2
ZXMgIkJpbmRpbmcgVXBkYXRlIiB3aXRoIDxDT0EgPSBNTidzIEhvbWUgQWRkcmVzcywgTGlmZXRp
bWUgPSAwPiwNCiAgICBpdCBjcmVhdGVzIG5vICJCaW5kaW5nIENhY2hlIiBhbmQgZGVsZXRlcyBl
eGlzdGluZyAiQmluZGluZyBDYWNoZSIgb3IgIlZpc2l0b3IgTGlzdCIgZm9yIHRoYXQgTU4gLi4u
Lg0KICAgIA0KICAgIEJ1dCwgd2hlbiBGQSByZWNlaXZlcyAiQmluZGluZyBVcGRhdGUiIGZvciBk
ZXJlZ2lzdGVyZWQgTU4gZnJvbSBIQSwNCiAgICBpdCBtYWtlcyBhICJCaW5kaW5nIENhY2hlIiBm
b3IgTU4gd2l0aCA8Q09BID0gTlVMTCBvciBNTidzIEhvbWUgQWRkcmVzcz4gLi4gICAgIA0KICAg
IFRoZW4sIHdoZW4gRkEgcmVjZWl2ZXMgdHVubmVsZWQgZGF0YWdyYW1zIHRvIE1OIGZyb20gYW55
IG5vZGUsIA0KICAgIGl0IHJlLXJvdXRlcyB0aGVtIHRvIE1OJ3MgSG9tZSBOZXR3b3JrIGFuZCBz
ZW5kcyAiQmluZGluZyBXYXJuaW5nIiB0byBNTidzIEhBIC4uLg0KICAgIEhvdyBhYm91dCBpdCA/
ICAgIA0KDQo+IA0KPiBSZWdhcmRzLA0KPiBDaGFybGllIFAuDQo+IA0KPiANCj4gIlBhcmssIEh5
dW4gU2VvIiB3cm90ZToNCj4gDQo+ID4gSGVsbG8sIEFsbCAuLi4uDQo+ID4gSSBoYXZlIGEgcXVl
c3Rpb24gYWJvdXQgIlJvdXRlIE9wdGltaXphdGlvbiBpbiBNb2JpbGUgSVAiIC4uLg0KPiA+DQo+
ID4gV2hlbiBNTiBjb21lcyBiYWNrIEhvbWUgTmV0d29yaywgaXQgZG9lcyAiRGVyZWdpc3RyYXRp
b24iIHdpdGggaXRzIEhBIC4uLg0KPiA+IE1OIHNlbmRzICJSZWdpc3RyYXRpb24gUmVxdWVzdCIg
d2l0aCA8Q09BID0gTU4ncyBIb21lIEFkZHJlc3M+IHRvIEhBIC4uLg0KPiA+DQo+ID4gTU4gY2Fu
IGluY2x1ZGUgIlByZXZpb3VzIEZBIE5vdGlmaWNhdGlvbiBFeHRlbnNpb24iLCBpZiBwb3NzaWJs
ZSwNCj4gPiAgICAgVGhlbiwgSEEgc2VuZHMgIkJpbmRpbmcgVXBkYXRlIiB0byBNTidzIHByZXZp
b3VzIEZBIC4uDQo+ID4gICAgIEJpbmRpbmcgVXBkYXRlIDogPENPQSA9IE1OJ3MgSG9tZSBBZGRy
ZXNzLCAgTGlmZXRpbWUgPSAwPg0KPiA+DQo+ID4gICAgIFRoZSBvbGQgRkEgcmVjZWl2ZXMgdGhh
dCAiQmluZGluZyBVcGRhdGUiLA0KPiA+ICAgICB0aGVuIGl0IGRlbGV0ZXMgdmlzaXRvciBsaXN0
IGVudHJ5IGZvciB0aGF0IE1OIC4uLi4NCj4gPiAgICAgQW5kIGl0IGRvZXMgbm90IG1ha2UgIkJp
bmRpbmcgQ2FjaGUiIGZvciB0aGF0IE1ODQo+ID4gICAgIGJlY2F1c2UgPENPQSA9IE1OJ3MgSG9t
ZSBBZGRyZXNzLCBMaWZldGltZSA9IDA+Li4uDQo+ID4NCj4gPiBOb3csIFN1cHBvc2UgYSBDTiB0
aGF0IGhhcyAiQmluZGluZyBDYWNoZSIgPENPQSA9IE1OJ3Mgb2xkIEZBPiAuLi4NCj4gPiBXaGVu
IGl0IHNlbmRzIGRhdGFncmFtcyB0byBNTiwgaXQgdHVubmVscyB0aGVtIHRvIE1OJ3Mgb2xkIEZB
IC4uLg0KPiA+IFRoZW4gTU4ncyBvbGQgRkEgZGVjYXBzdWxhdGVzIHRoZW0NCj4gPiAgICAgYW5k
IHJlLXJvdXRlcyAobm90IHR1bm5lbHMpIHRoZW0gdG8gTU4ncyBIb21lIE5ldHdvcmsgLi4uDQo+
ID4gTU4ncyBvbGQgRkEgZG9lcyBub3Qgc2VuZCAiQmluZGluZyBXYXJuaW5nIiB0byBIQSBiZWNh
dXNlIGl0IGhhcyBubyAiQmluZGluZyBDYWNoZSIuLi4NCj4gPiBBbmQgQ04gY2FuIG5vdCByZWNl
aXZlICJCaW5kaW5nIFVwZGF0ZSIgZnJvbSBIQSAuLi4NCj4gPiBTbywgQ04gd2lsbCBjb3VudGlu
dW91c2x5IHR1bm5lbCBkYXRhZ3JhbXMgdW50aWwgaXQgZXhwaXJlcyAiQmluZGluZyBDYWNoZSIg
Zm9yIE1OIC4uDQo+ID4NCj4gPiBBbSBJIHJpZ2h0ID8NCj4gPiBBbnkgY29tbWVudHMgd2lsbCBi
ZSBhcHByZWNpYXRlZCAuLi4NCj4gPiBUaGFua3MgaW4gYWR2YW5jZSAuLi4NCj4gPg0KPiA+IC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gUGFyaywgSHl1biBTZW8N
Cj4gPiBHcmFkdWF0ZSBTdHVkZW50DQo+ID4gRGVwYXJ0bWVudCBvZiBDb21wdXRlciBFbmdpbmVl
cmluZywgQ2h1bmduYW0gTmF0aW9uYWwgVW5pdmVyc2l0eQ0KPiA+IDIyMCBHdW5nLWRvbmcsWXVT
ZW9uZy1HdSwgVGFlam9uLCAzMDU3NjQsIEtvcmVhDQo+ID4gRS1tYWlsOiBoc3BhcmtAY2UuY251
LmFjLmtyDQo+ID4gSUNRICMgOiAyODA1NTA5Mw0KPiA+IFBob25lIDogKzgyLTQyLTgyMy02MDQ5
DQo=

------=_NextPart_000_003D_01C044E2.4D9CE740
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz
by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1M
IDUuMDAuMjkxOS42MzA3IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE
Pg0KPEJPRFk+DQo8RElWPjxGT05UIGNvbG9yPSM4MDAwODAgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7
IHNpemU9Mj5UaGFua3MsIENoYXJsaWUgLi4uIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29s
b3I9IzgwMDA4MCBmYWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPk15IGNvbW1lbnRzIGFyZSBi
ZWxvdyAuLi4uPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj
ZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj4mZ3Q7IEhlbGxvLDxCUj4mZ3Q7IDxCUj4mZ3Q7IFll
cywgSSB0aGluayB5b3UgYXJlIA0KY29ycmVjdC4mbmJzcDsgSW4gdGhlIHBhc3QsIHRoZSBmb3Jl
aWduIGFnZW50IGhhZDxCUj4mZ3Q7IGJlZW4gYWxsb3dlZCB0byBzZW5kIGEgDQpCaW5kaW5nIFdh
cm5pbmcgdG8gdGhlIGNvcnJlc3BvbmRlbnQ8QlI+Jmd0OyBub2RlLiZuYnNwOyBJIHRob3VnaHQg
dGhhdCBpdCBzdGlsbCANCmNvdWxkIGRvIHNvLCBidXQgdXBvbiByZS1yZWFkaW5nIHRoZTxCUj4m
Z3Q7IHNwZWNpZmljYXRpb24gSSBzZWUgdGhhdCBpdCBpc24ndCANCmluIHRoZXJlIG5vdy4mbmJz
cDsgV2UgY291bGQgc2F5IHRoYXQ8QlI+Jmd0OyB0aGUgZm9yZWlnbiBhZ2VudCBTSE9VTEQgc2Vu
ZCBhIA0KQmluZGluZyBXYXJuaW5nIHRvIHRoZTxCUj4mZ3Q7IGNvcnJlc3BvbmRlbnQgbm9kZSwg
aWYgdGhlIGZvcmVpZ24gYWdlbnQgZG9lcyBub3QgDQpoYXZlIGFueTxCUj4mZ3Q7IHJlY29yZCBv
ZiB0aGUgaG9tZSBhZ2VudCBmb3IgdGhlIG1vYmlsZSBub2RlLiZuYnNwOyANCjwvRk9OVD48L0RJ
Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSM4MDAwODAgZmFjZT0mIzQ0
NDA0OyYjNDc1NDg7IHNpemU9Mj5bUGFya10mbmJzcDtJIHRoaW5rJm5ic3A7RkEgc2VuZHMgYSAN
CiJCaW5kaW5nIFdhcm5pbmciJm5ic3A7dG8mbmJzcDtub3QgQ04mbmJzcDtidXQgSEEgLi4uPC9G
T05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jODAwMDgwIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4
OyBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFtIEkgY29ycmVjdCA/Jm5ic3A7IA0KPC9GT05U
PjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1
NDg7IHNpemU9Mj4mZ3Q7IFRoZSBjb3JyZXNwb25kZW50Jm5ic3A7bm9kZSBwcmVzdW1hYmx5IHdp
bGwgDQp1bmRlcnN0YW5kIHRoZSBtZXNzYWdlLCA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh
Y2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+Jmd0OyBzaW5jZSBpdCdzIHN0YWxlJm5ic3A7Ymlu
ZGluZyBmb3IgdGhlIG1vYmlsZSBub2RlIA0Kd2FzIHByb2R1Y2VkIGJ5IHByb2Nlc3NpbmcgYTxC
Uj4mZ3Q7IHByZXZpb3VzJm5ic3A7IEJpbmRpbmcgVXBkYXRlIGluIHRoZSBmaXJzdCANCnBsYWNl
LjxCUj4mZ3Q7IDxCUj4mZ3Q7IERvZXMgdGhpcyBzb2x2ZSB0aGUgcHJvYmxlbT88L0ZPTlQ+PC9E
SVY+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+PC9GT05UPiZuYnNw
OzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPjxGT05UIGNv
bG9yPSM4MDAwODA+W1BhcmtdIEhvdyBhYm91dCAiQmluZGluZyBDYWNoZSANCmZvciBEZXJlZ2lz
dGVyZWQgTU4iID88L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jODAwMDgw
IGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdoZW4gYW55
IG5vZGUgDQpyZWNlaXZlcyAiQmluZGluZyBVcGRhdGUiIHdpdGggJmx0O0NPQSA9IE1OJ3MgSG9t
ZSBBZGRyZXNzLCBMaWZldGltZSA9IA0KMCZndDssPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBj
b2xvcj0jODAwMDgwIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7IGl0IGNyZWF0ZXMgbm8gDQoiQmluZGluZyBDYWNoZSIgYW5kIGRlbGV0ZXMgZXhpc3Rpbmcg
IkJpbmRpbmcgQ2FjaGUiIG9yICJWaXNpdG9yIExpc3QiIGZvciB0aGF0IA0KTU4gLi4uLjwvRk9O
VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj48Rk9OVCAN
CmNvbG9yPSM4MDAwODA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjwvRk9OVD48L0RJ
Vj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj48Rk9OVCBjb2xvcj0j
ODAwMDgwPiZuYnNwOyZuYnNwOyZuYnNwOyBCdXQsIHdoZW4gRkEgDQpyZWNlaXZlcyAiQmluZGlu
ZyBVcGRhdGUiIGZvciBkZXJlZ2lzdGVyZWQgTU4gZnJvbSBIQSw8L0ZPTlQ+PC9GT05UPjwvRElW
Pg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPjxGT05UIGNvbG9yPSM4
MDAwODA+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGl0IG1ha2VzIGEgDQoiQmluZGluZyBDYWNoZSImbmJz
cDtmb3IgTU4gd2l0aCAmbHQ7Q09BID0gTlVMTCBvciBNTidzIEhvbWUgQWRkcmVzcyZndDsgLi4g
DQombmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29s
b3I9IzgwMDA4MCBmYWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNw
OyBUaGVuLCB3aGVuIEZBIA0KcmVjZWl2ZXMgdHVubmVsZWQgZGF0YWdyYW1zIHRvIE1OIGZyb20g
YW55IG5vZGUsIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzgwMDA4MCBmYWNlPSYj
NDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyBpdCByZS1yb3V0ZXMgdGhl
bSB0byANCk1OJ3MgSG9tZSBOZXR3b3JrIGFuZCBzZW5kcyAiQmluZGluZyBXYXJuaW5nIiB0byBN
TidzIEhBIC4uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzgwMDA4MCBmYWNlPSYj
NDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0hvdyBhYm91dCBp
dCANCj8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh
Y2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+PEZPTlQgY29sb3I9IzgwMDA4MD48QlI+PC9GT05U
PiZndDsgPEJSPiZndDsgDQpSZWdhcmRzLDxCUj4mZ3Q7IENoYXJsaWUgUC48QlI+Jmd0OyA8QlI+
Jmd0OyA8QlI+Jmd0OyAiUGFyaywgSHl1biBTZW8iIA0Kd3JvdGU6PEJSPiZndDsgPEJSPiZndDsg
Jmd0OyBIZWxsbywgQWxsIC4uLi48QlI+Jmd0OyAmZ3Q7IEkgaGF2ZSBhIHF1ZXN0aW9uIA0KYWJv
dXQgIlJvdXRlIE9wdGltaXphdGlvbiBpbiBNb2JpbGUgSVAiIC4uLjxCUj4mZ3Q7ICZndDs8QlI+
Jmd0OyAmZ3Q7IFdoZW4gTU4gDQpjb21lcyBiYWNrIEhvbWUgTmV0d29yaywgaXQgZG9lcyAiRGVy
ZWdpc3RyYXRpb24iIHdpdGggaXRzIEhBIC4uLjxCUj4mZ3Q7ICZndDsgDQpNTiBzZW5kcyAiUmVn
aXN0cmF0aW9uIFJlcXVlc3QiIHdpdGggJmx0O0NPQSA9IE1OJ3MgSG9tZSBBZGRyZXNzJmd0OyB0
byBIQSANCi4uLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IE1OIGNhbiBpbmNsdWRlICJQcmV2
aW91cyBGQSBOb3RpZmljYXRpb24gDQpFeHRlbnNpb24iLCBpZiBwb3NzaWJsZSw8QlI+Jmd0OyAm
Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZW4sIEhBIHNlbmRzIA0KIkJpbmRpbmcgVXBk
YXRlIiB0byBNTidzIHByZXZpb3VzIEZBIC4uPEJSPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyANCkJpbmRpbmcgVXBkYXRlIDogJmx0O0NPQSA9IE1OJ3MgSG9tZSBBZGRyZXNzLCZu
YnNwOyBMaWZldGltZSA9IDAmZ3Q7PEJSPiZndDsgDQomZ3Q7PEJSPiZndDsgJmd0OyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBUaGUgb2xkIEZBIHJlY2VpdmVzIHRoYXQgIkJpbmRpbmcgDQpVcGRh
dGUiLDxCUj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlbiBpdCBkZWxldGVz
IHZpc2l0b3IgbGlzdCBlbnRyeSANCmZvciB0aGF0IE1OIC4uLi48QlI+Jmd0OyAmZ3Q7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFuZCBpdCBkb2VzIG5vdCBtYWtlIA0KIkJpbmRpbmcgQ2FjaGUi
IGZvciB0aGF0IE1OPEJSPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiZWNhdXNl
ICZsdDtDT0EgDQo9IE1OJ3MgSG9tZSBBZGRyZXNzLCBMaWZldGltZSA9IDAmZ3Q7Li4uPEJSPiZn
dDsgJmd0OzxCUj4mZ3Q7ICZndDsgTm93LCBTdXBwb3NlIA0KYSBDTiB0aGF0IGhhcyAiQmluZGlu
ZyBDYWNoZSIgJmx0O0NPQSA9IE1OJ3Mgb2xkIEZBJmd0OyAuLi48QlI+Jmd0OyAmZ3Q7IFdoZW4g
aXQgDQpzZW5kcyBkYXRhZ3JhbXMgdG8gTU4sIGl0IHR1bm5lbHMgdGhlbSB0byBNTidzIG9sZCBG
QSAuLi48QlI+Jmd0OyAmZ3Q7IFRoZW4gTU4ncyANCm9sZCBGQSBkZWNhcHN1bGF0ZXMgdGhlbTxC
Uj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5kIHJlLXJvdXRlcyAobm90IA0K
dHVubmVscykgdGhlbSB0byBNTidzIEhvbWUgTmV0d29yayAuLi48QlI+Jmd0OyAmZ3Q7IE1OJ3Mg
b2xkIEZBIGRvZXMgbm90IHNlbmQgDQoiQmluZGluZyBXYXJuaW5nIiB0byBIQSBiZWNhdXNlIGl0
IGhhcyBubyAiQmluZGluZyBDYWNoZSIuLi48QlI+Jmd0OyAmZ3Q7IEFuZCBDTiANCmNhbiBub3Qg
cmVjZWl2ZSAiQmluZGluZyBVcGRhdGUiIGZyb20gSEEgLi4uPEJSPiZndDsgJmd0OyBTbywgQ04g
d2lsbCANCmNvdW50aW51b3VzbHkgdHVubmVsIGRhdGFncmFtcyB1bnRpbCBpdCBleHBpcmVzICJC
aW5kaW5nIENhY2hlIiBmb3IgTU4gDQouLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IEFtIEkg
cmlnaHQgPzxCUj4mZ3Q7ICZndDsgQW55IGNvbW1lbnRzIHdpbGwgYmUgDQphcHByZWNpYXRlZCAu
Li48QlI+Jmd0OyAmZ3Q7IFRoYW5rcyBpbiBhZHZhbmNlIC4uLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0
OyAmZ3Q7IA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+Jmd0OyAm
Z3Q7IFBhcmssIEh5dW4gU2VvPEJSPiZndDsgJmd0OyANCkdyYWR1YXRlIFN0dWRlbnQ8QlI+Jmd0
OyAmZ3Q7IERlcGFydG1lbnQgb2YgQ29tcHV0ZXIgRW5naW5lZXJpbmcsIENodW5nbmFtIA0KTmF0
aW9uYWwgVW5pdmVyc2l0eTxCUj4mZ3Q7ICZndDsgMjIwIEd1bmctZG9uZyxZdVNlb25nLUd1LCBU
YWVqb24sIDMwNTc2NCwgDQpLb3JlYTxCUj4mZ3Q7ICZndDsgRS1tYWlsOiA8L0ZPTlQ+PEEgaHJl
Zj0ibWFpbHRvOmhzcGFya0BjZS5jbnUuYWMua3IiPjxGT05UIA0KZmFjZT0mIzQ0NDA0OyYjNDc1
NDg7IHNpemU9Mj5oc3BhcmtAY2UuY251LmFjLmtyPC9GT05UPjwvQT48QlI+PEZPTlQgZmFjZT0m
IzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj4mZ3Q7ICZndDsgDQpJQ1EgIyA6IDI4MDU1MDkzPEJSPiZn
dDsgJmd0OyBQaG9uZSA6ICs4Mi00Mi04MjMtNjA0OTwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1M
Pg0K

------=_NextPart_000_003D_01C044E2.4D9CE740--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  2 02:14:38 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23513
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Nov 2000 02:14:37 -0500 (EST)
Received: from standards (47.234.32.16:1148) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE64F@standards.nortelnetworks.com>; Thu, 2 Nov 2000 1:56:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 67739 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 01:56:39 -0500
Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBAE64B@standards.nortelnetworks.com>;
          Thu, 2 Nov 2000 1:46:34 -0500
Received: from cc.hut.fi (root@alpha.hut.fi [130.233.224.50]) by smtp-2.hut.fi
          (8.9.3/8.9.3) with ESMTP id JAA83183; Thu, 2 Nov 2000 09:02:20 +0200
          (EET)
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i586)
X-Accept-Language: en
MIME-Version: 1.0
References: <3.0.32.20001027101806.00ea4abc@era-t.ericsson.se>
            <39FB2C30.4A80518D@cc.hut.fi> <02ae01c04161$8132d800$878bf3cd@piii>
            <39FC04C3.43DBD172@cc.hut.fi> <39FECE59.5FFBD9DB@iprg.nokia.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Approved-By:  tom@SMTP.HUT.FI
Message-ID:  <3A011195.22B819CA@cc.hut.fi>
Date:         Thu, 2 Nov 2000 09:02:45 +0200
Reply-To: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" <tweckstr@cc.hut.fi>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" <tweckstr@cc.hut.fi>
Organization: HUT
Subject:      Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt)
X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
X-cc:         Satwant Kaur <wizkid11@xnet.com>,
              Annika.Jonsson@era.ericsson.se, Eva Gustafsson 
              <Eva.Gustafsson@ERICSSON.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

Hello Charlie.

"Charles E. Perkins" wrote:
>
> I have studied your examples, and I have two overall
> comments.
>
> It seems to me that using the Previous Foreign Agent
> Notification (PFAN) extension (from the Route Optimization
> draft) solves the problems that you posed.  This message
> forces an acknowledgement from the previous foreign agent
> after it receives the Binding Update.  Thus, the mobile
> node has a way to know its registration status at previous
> foreign agents.  All along, we tried to make the regional
> registration draft coexist well with the Binding Update
> mechanism specified in the Route Optimization draft, while
> still remaining sufficiently independent so that the
> regional registration draft could be considered separately.
>
> Do you agree that this is a good solution?

I understand. Syncing with other drafts makes sense.
However, can you refer to a draft from an RFC? I mean, what if the
current Route optim. I-D is not accepted as is? This means you might
need to change your RFC also...

Let me tell you how I understood the scheme. Correct my
misunderstandings. I did not have time to read the Route optim. I-D
through.

This describes FA4-->FA3 handoff in the picture below. MN is changing
its FA. Regional registration request has been sent. The request
arrives to the new FA, FA3. It does not know the MN so it forwards the
request upwards in the hierarchy. The next FA, FA1, knows the MN and
has a binding for it. The old care of address (previous FA IP, FA4's
IP) is in that binding. FA1 processing the request sends a
registration reply to MN. FA1 also sends the PFAN extension in some
rot of a message (authentication???) to the previous FA, FA4. The
previous FA sets the MN's new COA to its binding cache for a while.
The previous FA sends an acknowledgement to MN about having received
the PFAN. MN knows now that
A) the registration to FA3 was successful (because of the reg.reply)
B) the previous FA, FA4, has been informed.

Now, consider a deeper hierarchy example. MN changes from FA6 to FA4
in the picture below. Registration rewuest goes to GFA. GFA knows MN.
GFA sends reg.reply. GFA sends PFAN. To which FA does the GFA send
that PFAN? To FA2? To FA6? The PFAN must go through FA2 also. Does GFA
need to have both the FA2 and the FA6 addresses in its binding?
Meaning, GFA would know the entire path from GFA to MN. How can a FA
know, whether it should process the request or not? I mean, having a
binding for the MN ("knowing" the MN) is not enough, because a FA can
not trust the unreliable network. So, we agree that FA needs to get
info about the prefious FA. But do the FAs also need information about
the hierarchy? I.e., does each FA have to know, which FAs are under
it? I would say yes. Then the PFAN or "previous FA NAI" approaches
will work.

I haven't modeled all the scenarios, but if a FA does not know what
FAs are under it in the hierarchy, it can not be sure whether it
should process the request or consider its own binding an obsolete
"relic" because of a lost PFAN message that was previously send to it.

The knowledge about FAs under each FA should be complete. I.e., it is
not enough for a FA to only know the path to the MN through the FAs
under the FA. This is because of a possibility of lost protocol
messages in the hierarchy.

Of course, one can always say that the protocol recovers from this
kind of situations with timeouts (reg.reply timeout in MN and binding
timeout in FAs) but that would not support efficient, fast roaming in
a network with slight probability of lost packets...

What do you think?
Should the FAs know about all the FAs under them?



> I am very tempted to agree with you about the need to
> insure that regional registration messages work with multilevel
> hierarchies.  And, in fact, I think that the messages in the
> current draft do work in multilevel hierarchies.  We all
> thought about this problem of multi-level hierarchies many
> times, and that was a partial motivation for using different
> message types.  However, if you see any particular place where
> there is any existing problem in the protocol, where the
> regional messages would not work for the multi-level hierarchy,
> please let us know.

The only thing I am little bit unsure of, is the knowledge about other
FAs below each FA as I explained above. I am quite sure there will be
problems because of lost messages, if each FA does not know the FAs
underneath.

> For convenience, I have reproduced your example hierarchy
> and mobility patterns below.  I think that, given PFAN,
> the existing draft solves your concerns, but again if I am
> wrong I hope you will help us find out what is still wrong.

If you also considered cases of lost messages, please let me know and
tell me how the "PFAN only" approach with FAs not knowing the FAs
underneath solved those cases.


Best regards,
                Tom


> > Again, I use the example hierarchy:
> >
> >                                  ------
> >                                  | HA |
> >                                  ------
> >                                    |
> >                                (Internet)
> >                                    |
> >                                 -------
> >                                 | GFA |
> >                                 -------
> >                               /         \
> >                       -------             -------
> >                       | FA1 |             | FA2 |
> >                       -------             -------
> >                        /   \               /   \
> >                  -------   -------   -------   -------
> >                  | FA3 |   | FA4 |   | FA5 |   | FA6 |
> >                  -------   -------   -------   -------
> >                                   \
> >                                    \
> >                                  ------
> >                                  | MN |
> >                                  ------
> >
> > In the initial situation in the figure, IFA (FA1) is the intermediate
> > FA on a path from HA to MN, GFA has its own special name and role, and
> > LFA (FA4) is the lowest FA on a path from HA to MN. MN has registered
> > with a home registration and has received a reply through FA4 (LFA).
> >
> > Now, consider a situation, in which MN changes its lowest FA (the FA
> > to which it sends its registrations) in the following order:
> > -- FA4, FA3, FA6, FA5, FA4,...
> >
> > Now, what entities send the regional registration reply to MN?
> > In the corresponding order:
> > -- FA1, FA1, GFA, FA2, GFA,...
> >
> > Now, also FA1 and FA2, and even GFA may send agent advertisements.
> > MN could also roam vertically and register like this:
> > -- FA4, FA1, FA2, FA3, FA2, FA6, FA1
> >
> > And the FA sending the registration reply would be:
> > -- FA1, FA1, GFA, GFA, GFA, FA2, GFA

--
        Tom Weckström           tweckstr@cc.hut.fi
        Korppaanmäentie 16 B 14 Helsinki University of Technology
        00300 Helsinki          Department of Computer Science
        040-5642709             http://www.niksula.cs.hut.fi/~tweckstr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  2 11:06:31 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04199
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Nov 2000 11:06:29 -0500 (EST)
Received: from standards (47.234.32.16:2408) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE9F4@standards.nortelnetworks.com>; Thu, 2 Nov 2000 10:48:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 68989 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 10:48:38 -0500
Received: from cisco.com (sigma.cisco.com) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBAE9F2@standards.nortelnetworks.com>; Thu, 2 Nov 2000 10:48:37
          -0500
Received: from kleung-home.cisco.com (kleung-dsl2.cisco.com [10.19.54.3]) by
          cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA27083 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 2 Nov 2000 08:04:32
          -0800 (PST)
X-Sender: kleung@sigma.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Approved-By:  Kent Leung <kleung@CISCO.COM>
Message-ID:  <4.3.2.7.2.20001102074035.00cd7db0@sigma.cisco.com>
Date:         Thu, 2 Nov 2000 07:57:05 -0800
Reply-To: Kent Leung <kleung@cisco.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Kent Leung <kleung@cisco.com>
Subject:      [MOBILE-IP] RFC 2344 Reverse Tunnel Broadcast/Multicast
              clarification
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

RFC 2344 Reverse Tunnel clarification request:

Here's the section:
------------------------------------------------------------
5.3. Support for Broadcast and Multicast Datagrams

    If a mobile node is operating with a co-located care-of address,
    broadcast and multicast datagrams are handled according to Sections
    4.3 and 4.4 of the Mobile IP specification [1]. Mobile nodes using a
    foreign agent care-of address MAY have their broadcast and multicast
    datagrams reverse-tunneled by the foreign agent.  However, any mobile
    nodes doing so MUST use the encapsulating delivery style.

    This delivers the datagram only to the foreign agent.  The latter
    decapsulates it and then processes it as any other packet from the
    mobile node, namely, by reverse tunneling it to the home agent.

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

This doesn't seem to cover how FA should deal with reverse tunnel in Direct
Delivery Style?  What is the explicit behavior of FA when it receives
broadcast/multicast datagrams from MN in this Delivery mode?  Should FA
drop these packets since RFC is stating that Encap Delivery Style MUST be
used by MN?  Or should FA process them itself (which means local, not
reverse tunneling)?

Note that agent solicitations may be multicasts.

I'm interpreting that FA should process these packets, as in default
non-reverse tunnel behavior.  But would like to get explicit
definition.  Thanks.

-- Kent --


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  2 15:53:06 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16917
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Nov 2000 15:53:05 -0500 (EST)
Received: from standards (47.234.32.16:1187) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEC10@standards.nortelnetworks.com>; Thu, 2 Nov 2000 15:35:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 69722 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 15:35:02 -0500
Received: from mailhost.iprg.nokia.com (205.226.5.12:44912) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBAEC0E@standards.nortelnetworks.com>; Thu, 2 Nov 2000
          15:35:01 -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA23903;
          Thu, 2 Nov 2000 12:50:55 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA2Koqf30129; Thu, 2 Nov 2000 12:50:52
          -0800
X-Virus-Scanned:  Thu, 2 Nov 2000 12:50:52 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpd4URpnF; Thu, 02 Nov 2000
          12:46:43 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <00a601c0445d$d6c11800$c72ebca8@ce.cnu.ac.kr>
            <3A010205.D5D2D68D@iprg.nokia.com>
            <004001c04496$de125360$c72ebca8@ce.cnu.ac.kr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A01D2B3.AD5C6E71@iprg.nokia.com>
Date:         Thu, 2 Nov 2000 12:46:43 -0800
Reply-To: "Charles E. Perkins" <charliep@iprg.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] Question about "Route Optimization in Mobile IP"
X-To:         "Park, Hyun Seo" <hspark@ce.cnu.ac.kr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello again,

>>                                       We could say that
>> the foreign agent SHOULD send a Binding Warning to the
>> correspondent node, if the foreign agent does not have any
>> record of the home agent for the mobile node.
>
> [Park] I think FA sends a "Binding Warning" to not CN but HA ...
>     Am I correct ?

That's the way the specification reads now.  I am proposing that
a new revision of the Route Optimization draft be promulgated
that incorporates a new requirement, as outlined in my text
above your response.

>> The correspondent node presumably will understand the message,
>> since its stale binding for the mobile node was produced by processing
>> a previous Binding Update in the first place.
>>
>> Does this solve the problem?
>
> [Park] How about "Binding Cache for Deregistered MN" ?
>     When any node receives "Binding Update" with <COA = MN's Home Address,
>     Lifetime = 0>, it creates no "Binding Cache" and deletes existing
>     "Binding Cache" or "Visitor List" for that MN ....
>
>     But, when FA receives "Binding Update" for deregistered MN from HA,
>     it makes a "Binding Cache" for MN with <COA = NULL or MN's Home Address
>     Then, when FA receives tunneled datagrams to MN from any node,
>     it re-routes them to MN's Home Network and sends "Binding Warning"
>      to MN's HA ...     How about it ?

Then you would have to worry about how long that "deregistered"
visitor list entry would be maintained.  That seems like an
unnecessary complication for this hopefully rare case.

Besides, the Previous Foreign Agent Notification (PFAN) is supposed
to supply a binding with a nonzero lifetime to the previous foreign
agent.  If the home agent is the agent that issues the PFAN message,
then it should still not have a nonzero lifetime.  It is good that
you pointed this out, and we should make it explicit in the text.
I would rather set things up in this way, to be consistent with
roaming between foreign agents, than to introduce yet another timing
dependency with static timing parameters.

Regards,
Charlie P.

PS. I edited your response, purely for the purpose of making the lines
    fit better into my message reply window.  I hope you do not mind.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  2 22:47:37 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15505
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Nov 2000 22:47:36 -0500 (EST)
Received: from standards (47.234.32.16:2127) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAED77@standards.nortelnetworks.com>; Thu, 2 Nov 2000 22:29:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 70181 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 22:29:35 -0500
Received: from flower.comeng.chungnam.ac.kr by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBAED75@standards.nortelnetworks.com>; Thu, 2 Nov 2000 22:29:34
          -0500
Received: from Beethoven (Beethoven.comeng.chungnam.ac.kr [168.188.46.199]) by
          flower.comeng.chungnam.ac.kr (8.9.1/8.9.1) with SMTP id MAA06735 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 3 Nov 2000 12:40:05
          +0900 (KST)
References: <00a601c0445d$d6c11800$c72ebca8@ce.cnu.ac.kr>          
            <3A010205.D5D2D68D@iprg.nokia.com>          
            <004001c04496$de125360$c72ebca8@ce.cnu.ac.kr> 
            <3A01D2B3.AD5C6E71@iprg.nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Approved-By:  "Park, Hyun Seo" <hspark@CE.CNU.AC.KR>
Message-ID:  <01ae01c04548$7f6bb1a0$c72ebca8@ce.cnu.ac.kr>
Date:         Fri, 3 Nov 2000 12:45:23 +0900
Reply-To: "Park, Hyun Seo" <hspark@ce.cnu.ac.kr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Park, Hyun Seo" <hspark@ce.cnu.ac.kr>
Subject:      Re: [MOBILE-IP] Question about "Route Optimization in Mobile IP"
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA15505

Hello, again, too .... :-)

> Hello again,
> 
> >>                                       We could say that
> >> the foreign agent SHOULD send a Binding Warning to the
> >> correspondent node, if the foreign agent does not have any
> >> record of the home agent for the mobile node.
> >
> > [Park] I think FA sends a "Binding Warning" to not CN but HA ...
> >     Am I correct ?
> 
> That's the way the specification reads now.  I am proposing that
> a new revision of the Route Optimization draft be promulgated
> that incorporates a new requirement, as outlined in my text
> above your response.

[Park] Then, when CN receives "Binding Warning", what can CN do ?
    In present Route Optimization draft, when a Node, that is, HA receives "Binding Warning",
    it sends "Binding Update" to the target node in "Binding Warning" message ... 
    Please explain to me in detail ...  
 
> >> The correspondent node presumably will understand the message,
> >> since its stale binding for the mobile node was produced by processing
> >> a previous Binding Update in the first place.
> >>
> >> Does this solve the problem?
> >
> > [Park] How about "Binding Cache for Deregistered MN" ?
> >     When any node receives "Binding Update" with <COA = MN's Home Address,
> >     Lifetime = 0>, it creates no "Binding Cache" and deletes existing
> >     "Binding Cache" or "Visitor List" for that MN ....
> >
> >     But, when FA receives "Binding Update" for deregistered MN from HA,
> >     it makes a "Binding Cache" for MN with <COA = NULL or MN's Home Address
> >     Then, when FA receives tunneled datagrams to MN from any node,
> >     it re-routes them to MN's Home Network and sends "Binding Warning"
> >      to MN's HA ...     How about it ?
> 
> Then you would have to worry about how long that "deregistered"
> visitor list entry would be maintained.  That seems like an
> unnecessary complication for this hopefully rare case.

[Park] FA does not maintain "deregistered" visitor list ... 
    It maintains "deregistered" Binding Cache(?) ..
    
> Besides, the Previous Foreign Agent Notification (PFAN) is supposed
> to supply a binding with a nonzero lifetime to the previous foreign
> agent.  If the home agent is the agent that issues the PFAN message,
> then it should still not have a nonzero lifetime.  

[Park] In My Opinion, I do not think PFAN can not be used with nonzero lifetime ....
    HA can send "Binding Update" with a zero lifetime ... 
    Similarly, when HA receives PFAN with zero lifetime,
    it can send "Binding Update" with a zero lifetime to Old FA ...

> It is good that you pointed this out, and we should make it explicit in the text.
> I would rather set things up in this way, to be consistent with
> roaming between foreign agents, than to introduce yet another timing
> dependency with static timing parameters.

[Park] What is "timing dependency with static timing parameters" ?
    Perhaps I am missing something .. Please let me know ... 
    Thanks a lot, Charlie ...     

> Regards,
> Charlie P.
> 
> PS. I edited your response, purely for the purpose of making the lines
>     fit better into my message reply window.  I hope you do not mind.

[Park] Never mind .... ;-)



From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  2 23:08:43 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17854
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Nov 2000 23:08:43 -0500 (EST)
Received: from standards (47.234.32.16:2127) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEDE6@standards.nortelnetworks.com>; Thu, 2 Nov 2000 22:49:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 70327 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 22:49:57 -0500
Received: from mail0.u-aizu.ac.jp by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBAEDE4@standards.nortelnetworks.com>; Thu, 2 Nov 2000 22:49:56
          -0500
Received: from pross114.u-aizu.ac.jp (pross114 [163.143.180.102]) by
          mail0.u-aizu.ac.jp (8.9.3+3.1W/3.7Winternet-gw) with ESMTP id
          NAA06000 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 3 Nov
          2000 13:05:51 +0900 (JST)
Received: from u-aizu.ac.jp (localhost [127.0.0.1]) by pross114.u-aizu.ac.jp
          (8.9.3+3.1W/3.7Wistcmx+kanji) with ESMTP id NAA12115 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 3 Nov 2000 13:05:51
          +0900 (JST)
X-Mailer: Mozilla 4.7 [en_jp] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------7ED2B97B96B64BC4A1B23F16"
Approved-By:  sarikaya@U-AIZU.AC.JP
Message-ID:  <3A02399E.2D9FF731@u-aizu.ac.jp>
Date:         Fri, 3 Nov 2000 13:05:50 +0900
Reply-To: Behcet Sarikaya <sarikaya@u-aizu.ac.jp>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Behcet Sarikaya <sarikaya@u-aizu.ac.jp>
Organization: University of Aizu
Subject:      [MOBILE-IP] New I-D Available
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--------------7ED2B97B96B64BC4A1B23F16
Content-Type: text/plain; charset=iso-8859-9
Content-Transfer-Encoding: 7bit

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


        Title           : Mobile IPv6 Regional Paging
        Author(s)       : B. Sarikaya, H. Haverinen, J.T. Malinen, V.
Magret
        Filename        : draft-sarikaya-mobileip-hmipv6rp-00.txt
        Pages           : 16
        Date            : 01-Nov-00

This document specifies Hierarchical Mobile IPv6 Regional Paging
   (HMIPv6RP), a small and link-layer independent extension to the
   Hierarchical Mobile IPv6 with regional registrations, to support
   power-constrained operation in the mobile nodes and to reduce routing

   state information in the visited domain.  The extension allows a
   mobile node to enter a power saving idle mode during which its
   location is known with the coarse accuracy defined by a paging area.
   In the visited domain only the paging mobility anchor point (PMAP) is

   responsible for keeping the binding cache entries for idle mobile
   nodes and, it re-establishes the downlink routes on demand by means
   of paging. This does not require snooping of data packets but is a
   natural extension to network-level routing. Optionally, the mobile
  node and the visited domain can agree on time slot based paging used
   for Paging Agent Advertisements to restrict link interface power-on
   time in the mobile node.

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





--------------7ED2B97B96B64BC4A1B23F16
Content-Type: text/html; charset=iso-8859-9
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
A New Internet-Draft is available from the on-line Internet-Drafts directories.
<br>&nbsp;
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: Mobile IPv6 Regional Paging
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: B. Sarikaya, H. Haverinen, J.T. Malinen, V. Magret
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: draft-sarikaya-mobileip-hmipv6rp-00.txt
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: 16
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: 01-Nov-00
<p>This document specifies Hierarchical Mobile IPv6 Regional Paging
<br>&nbsp;&nbsp; (HMIPv6RP), a small and link-layer independent extension
to the
<br>&nbsp;&nbsp; Hierarchical Mobile IPv6 with regional registrations,
to support
<br>&nbsp;&nbsp; power-constrained operation in the mobile nodes and to
reduce routing
<br>&nbsp;&nbsp; state information in the visited domain.&nbsp; The extension
allows a
<br>&nbsp;&nbsp; mobile node to enter a power saving idle mode during which
its
<br>&nbsp;&nbsp; location is known with the coarse accuracy defined by
a paging area.
<br>&nbsp;&nbsp; In the visited domain only the paging mobility anchor
point (PMAP) is
<br>&nbsp;&nbsp; responsible for keeping the binding cache entries for
idle mobile
<br>&nbsp;&nbsp; nodes and, it re-establishes the downlink routes on demand
by means
<br>&nbsp;&nbsp; of paging. This does not require snooping of data packets
but is a
<br>&nbsp;&nbsp; natural extension to network-level routing. Optionally,
the mobile
<br>&nbsp; node and the visited domain can agree on time slot based paging
used
<br>&nbsp;&nbsp; for Paging Agent Advertisements to restrict link interface
power-on
<br>&nbsp;&nbsp; time in the mobile node.
<p>A URL for this Internet-Draft is:
<br><A HREF="http://www.ietf.org/internet-drafts/draft-sarikaya-mobileip-hmipv6rp-00.txt">http://www.ietf.org/internet-drafts/draft-sarikaya-mobileip-hmipv6rp-00.txt</A>
<br>&nbsp;
<pre></pre>
&nbsp;</html>

--------------7ED2B97B96B64BC4A1B23F16--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 01:52:53 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08222
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 01:52:52 -0500 (EST)
Received: from standards (47.234.32.16:1449) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEE8F@standards.nortelnetworks.com>; Fri, 3 Nov 2000 1:32:48 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 70546 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 01:32:48 -0500
Received: from ish7.ericsson.com.au (203.61.155.111:54993) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBAEE8D@standards.nortelnetworks.com>; Fri, 3 Nov 2000 1:32:47
          -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id RAA18405 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 3 Nov 2000 17:45:33
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA13389 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 3 Nov 2000 17:48:11
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <V42TVZZQ>; Fri, 3 Nov 2000 17:48:20 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613D72@eaubrnt018.epa.ericsson.se>
Date:         Fri, 3 Nov 2000 17:48:11 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      [MOBILE-IP] FYI
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi all,

Just an FYI,  I submitted a new version of the Fast Handoffs draft for
IPv6 (draft-elmalki-handoffv6-01) and will be available on line in the
next day or two.

The changes :

- Removed IPR statement

- Details on ND handling

- Explanation on handling flat architecture within the
proposed solution.

- A new section on ping pong.

- Extra edits and clarification everywhere

The draft is one of the proposals  considered by the handoffs design
team so this is just a mail to inform everyone about the new
revision and be compliant with the IETF rules about drafts being
discussed in design teams .... nothing more !

Cheers,
Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 09:57:06 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03496
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 09:57:05 -0500 (EST)
Received: from standards (47.234.32.16:2012) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF04F@standards.nortelnetworks.com>; Fri, 3 Nov 2000 9:38:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 71139 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 09:38:57 -0500
Received: from cbin2-mail.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBAF04D@standards.nortelnetworks.com>; Fri, 3 Nov 2000 9:38:56
          -0500
Received: from cisco.com ([64.104.134.105]) by cbin2-mail.cisco.com
          (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA20361 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 3 Nov 2000 20:24:20
          +0530 (IST)
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Ravindra Rathi <rathi@CISCO.COM>
Message-ID:  <3A02D145.729B2D94@cisco.com>
Date:         Fri, 3 Nov 2000 20:22:53 +0530
Reply-To: Ravindra Rathi <rathi@cisco.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ravindra Rathi <rathi@cisco.com>
Subject:      [MOBILE-IP] RFC-2006 MIB upgrade is required
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello all,
        At present  tables in RFC-2006 MIB are indexed by ipaddress with
the assumption that each mobile node(MN) is uniquely going to be
identified by the
ipaddress. Now since MN can be identified by network access identifier
(NAI) and
ipaddress assigned to MN can change across registrations with
home-agent,
tables in MIB need to support NAI to reflect correct information.

Thanks,
Rathi


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 10:34:17 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12326
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 10:34:16 -0500 (EST)
Received: from standards (47.234.32.16:2012) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF125@standards.nortelnetworks.com>; Fri, 3 Nov 2000 10:16:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 71405 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 10:16:25 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBAF123@standards.nortelnetworks.com>; Fri, 3 Nov 2000 10:16:25
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA28165;
          Fri, 3 Nov 2000 07:32:23 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA3FWMB01162; Fri, 3 Nov 2000 07:32:22
          -0800
X-Virus-Scanned:  Fri, 3 Nov 2000 07:32:22 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdSrTSxS; Fri, 03 Nov 2000
          07:32:18 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <3A02D145.729B2D94@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A02DA83.C0DDB8C7@iprg.nokia.com>
Date:         Fri, 3 Nov 2000 07:32:19 -0800
Reply-To: "Charles E. Perkins" <charliep@iprg.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] RFC-2006 MIB upgrade is required
X-To:         Ravindra Rathi <rathi@cisco.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Rathi,

By the time the MIB stuff needs to be maintained,
the mobile node DOES have an IP address.

I think that should make it O.K.

Regards,
Charlie P.



Ravindra Rathi wrote:
>
> Hello all,
>         At present  tables in RFC-2006 MIB are indexed by ipaddress with
> the assumption that each mobile node(MN) is uniquely going to be
> identified by the
> ipaddress. Now since MN can be identified by network access identifier
> (NAI) and
> ipaddress assigned to MN can change across registrations with
> home-agent,
> tables in MIB need to support NAI to reflect correct information.
>
> Thanks,
> Rathi


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 10:45:27 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14925
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 10:45:27 -0500 (EST)
Received: from standards (47.234.32.16:2012) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF17D@standards.nortelnetworks.com>; Fri, 3 Nov 2000 10:27:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 71517 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 10:27:40 -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBAF17B@standards.nortelnetworks.com>;
          Fri, 3 Nov 2000 10:27:40 -0500
Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id IAA03194; Fri, 3 Nov 2000 08:43:37
          -0700 (MST)
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,v1.7) with ESMTP id
          HAA05479; Fri, 3 Nov 2000 07:43:36 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id HAA26746; Fri, 3 Nov 2000 07:43:35
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Patrice Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.973266061.16547.pcalhoun@nasnfs>
Date:         Fri, 3 Nov 2000 07:41:01 -0800
Reply-To: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] RFC-2006 MIB upgrade is required
X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" <3A02DA83.C0DDB8C7@iprg.nokia.com>

> Hello Rathi,
>
> By the time the MIB stuff needs to be maintained,
> the mobile node DOES have an IP address.

Correct. However, if one wants to be able to manage a particular mobile node,
the only static information is the NAI. So, the current MIB forces one to scan
through all Mobile Node entries looking specifically for the NAI.

>
> I think that should make it O.K.

Perhaps, as specified it is very tedious.

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 11:46:49 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02027
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 11:46:48 -0500 (EST)
Received: from standards (47.234.32.16:3710) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF1FD@standards.nortelnetworks.com>; Fri, 3 Nov 2000 11:28:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 71681 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 11:28:50 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBAF1FB@standards.nortelnetworks.com>; Fri, 3 Nov 2000 11:28:50
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA03527;
          Fri, 3 Nov 2000 08:44:48 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA3Giiv22853; Fri, 3 Nov 2000 08:44:44
          -0800
X-Virus-Scanned:  Fri, 3 Nov 2000 08:44:44 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdA09n4u; Fri, 03 Nov 2000
          08:44:02 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <00a601c0445d$d6c11800$c72ebca8@ce.cnu.ac.kr>
            <3A010205.D5D2D68D@iprg.nokia.com>
            <004001c04496$de125360$c72ebca8@ce.cnu.ac.kr>
            <3A01D2B3.AD5C6E71@iprg.nokia.com>
            <01ae01c04548$7f6bb1a0$c72ebca8@ce.cnu.ac.kr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A02EB55.3C7205C5@iprg.nokia.com>
Date:         Fri, 3 Nov 2000 08:44:05 -0800
Reply-To: "Charles E. Perkins" <charliep@iprg.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] Question about "Route Optimization in Mobile IP"
X-To:         "Park, Hyun Seo" <hspark@ce.cnu.ac.kr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Park,

> [Park] Then, when CN receives "Binding Warning", what can CN do ?
>     In present Route Optimization draft, when a Node, that is, HA receives
>     "Binding Warning", it sends "Binding Update" to the target node in
>     "Binding Warning" message ... Please explain to me in detail ...

The Correspondent Node should delete its binding for the mobile
node.  Then packets will go to the home network.  Then the home
agent will send a Binding Update, or else the mobile node will.


>> Then you would have to worry about how long that "deregistered"
>> visitor list entry would be maintained.  That seems like an
>> unnecessary complication for this hopefully rare case.
>
> [Park] FA does not maintain "deregistered" visitor list ...
>     It maintains "deregistered" Binding Cache(?) ..

O.K.  I am not picky about this point :-)


>> Besides, the Previous Foreign Agent Notification (PFAN) is supposed
>> to supply a binding with a nonzero lifetime to the previous foreign
>> agent.  If the home agent is the agent that issues the PFAN message,
>> then it should still not have a nonzero lifetime.
>
> [Park] In My Opinion, I do not think PFAN can not be used with nonzero
>     lifetime ....  HA can send "Binding Update" with a zero lifetime ...
>     Similarly, when HA receives PFAN with zero lifetime,
>     it can send "Binding Update" with a zero lifetime to Old FA ...

O.K. with me.  Why would the home agent get a PFAN with zero lifetime?



>> It is good that you pointed this out, and we should make it explicit in
>> the text. I would rather set things up in this way, to be consistent with
>> roaming between foreign agents, than to introduce yet another timing
>> dependency with static timing parameters.
>
> [Park] What is "timing dependency with static timing parameters" ?
>     Perhaps I am missing something .. Please let me know ...
>     Thanks a lot, Charlie ...

I was trying to imagine how a mobile agent would know when to delete
its entry for this:

> [Park] How about "Binding Cache for Deregistered MN" ?
>     When any node receives "Binding Update" with <COA = MN's Home Address,
>     Lifetime = 0>, it creates no "Binding Cache" and deletes existing
>     "Binding Cache" or "Visitor List" for that MN ....
>
>     But, when FA receives "Binding Update" for deregistered MN from HA,
>     it makes a "Binding Cache" for MN with <COA = NULL or MN's Home Address
>     Then, when FA receives tunneled datagrams to MN from any node,
>     it re-routes them to MN's Home Network and sends "Binding Warning"
>      to MN's HA ...     How about it ?

What would you suggest other than some preconfigured static timing
parameter, indicated either by the home agent or the foreign agent?

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 11:54:55 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04740
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 11:54:54 -0500 (EST)
Received: from standards (47.234.32.16:3710) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF225@standards.nortelnetworks.com>; Fri, 3 Nov 2000 11:32:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 71730 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 11:32:01 -0500
Received: from cisco.com (sigma.cisco.com) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBAF223@standards.nortelnetworks.com>; Fri, 3 Nov 2000 11:32:01
          -0500
Received: from kleung-home.cisco.com (kleung-dsl2.cisco.com [10.19.54.3]) by
          cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA21671;
          Fri, 3 Nov 2000 08:47:58 -0800 (PST)
X-Sender: kleung@sigma.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
References: <"Your message with ID" <3A02DA83.C0DDB8C7@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Approved-By:  Kent Leung <kleung@CISCO.COM>
Message-ID:  <4.3.2.7.2.20001103082552.00cd5100@sigma.cisco.com>
Date:         Fri, 3 Nov 2000 08:40:28 -0800
Reply-To: Kent Leung <kleung@cisco.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Kent Leung <kleung@cisco.com>
Subject:      Re: [MOBILE-IP] RFC-2006 MIB upgrade is required
X-To:         Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <Roam.SIMC.2.0.6.973266061.16547.pcalhoun@nasnfs>

At 07:41 AM 11/03/2000 -0800, Patrice Calhoun wrote:

>Correct. However, if one wants to be able to manage a particular mobile node,
>the only static information is the NAI. So, the current MIB forces one to scan
>through all Mobile Node entries looking specifically for the NAI.

Yes, the MN is no longer identified by the home address (which may be
dynamically allocated), but its NAI.  So management should be based on NAI
for MNs that use NAI.

Perhaps, since NAI is directly tied to authentication, a higher abstraction
is a Service ID?  A Service ID would map directly to NAI if only one IP
address is allocated to an MN with NAI.  But it's possible in the future to
have same NAI used for authentication for different devices or services on
the same device, which requires individual IP addresses.  In this case each
individual binding has a unique Service ID.  So management of mobility
binding entry may need to be at the Service ID level?

Since we need a new RFC draft to support non-IP address identified MN, we
can aim for extensibility.  Just a thought.

-- Kent --


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 11:54:55 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04743
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 11:54:55 -0500 (EST)
Received: from standards (47.234.32.16:3710) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF260@standards.nortelnetworks.com>; Fri, 3 Nov 2000 11:35:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 71811 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 11:35:37 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBAF25E@standards.nortelnetworks.com>; Fri, 3 Nov 2000 11:35:36
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA03951;
          Fri, 3 Nov 2000 08:51:35 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA3GpWD31006; Fri, 3 Nov 2000 08:51:32
          -0800
X-Virus-Scanned:  Fri, 3 Nov 2000 08:51:32 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdR9HLmF; Fri, 03 Nov 2000
          08:51:26 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <Roam.SIMC.2.0.6.973266061.16547.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A02ED0F.B837A447@iprg.nokia.com>
Date:         Fri, 3 Nov 2000 08:51:27 -0800
Reply-To: "Charles E. Perkins" <charliep@iprg.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] RFC-2006 MIB upgrade is required
X-To:         Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Pat,

I said in response to Rathi's question:

>> By the time the MIB stuff needs to be maintained,
>> the mobile node DOES have an IP address.

You said:

> Correct. However, if one wants to be able to manage a particular mobile node,
> the only static information is the NAI. So, the current MIB forces one to scan
> through all Mobile Node entries looking specifically for the NAI.

Which node do you mean that is managing the particular mobile node?

- If it's AAAH, then I think there's no problem, except insofar as
  AAAH might want to be the SNMP master to acquire data from HA.

- If it's HA, then the HA that allows this feature "should"
  create pointers between its NAI indexed data and its IP
  addressed data.

- If it's FA, then I am surprised.

- If it's MN, then I am really surprised.

Furthermore, I would suggest that NAI-oriented MIB data
doesn't belong in the Mobile IP MIB.  NAIs are not network
layer things.  Maybe there needs to be "extension-specific"
MIB fields for the AAA MIB.  Errr.... is there such a thing
as an AAA MIB?  How about a Mobile IP extension MIB for AAA?

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 14:07:53 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13976
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 14:07:53 -0500 (EST)
Received: from standards (47.234.32.16:3355) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF374@standards.nortelnetworks.com>; Fri, 3 Nov 2000 13:50:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 72168 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 13:50:01 -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBAF372@standards.nortelnetworks.com>;
          Fri, 3 Nov 2000 13:50:00 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id MAA07960; Fri, 3 Nov 2000 12:05:57
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          LAA14603; Fri, 3 Nov 2000 11:05:55 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id LAA07334; Fri, 3 Nov 2000 11:05:54
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Patrice Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.973278201.18581.pcalhoun@nasnfs>
Date:         Fri, 3 Nov 2000 11:03:21 -0800
Reply-To: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] RFC-2006 MIB upgrade is required
X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" <3A02ED0F.B837A447@iprg.nokia.com>

>
> Which node do you mean that is managing the particular mobile node?
>
The HA. When walking through the various MIB entries, the NAI is not even
present, so it would be rather difficult to "identify" a Mobile Node. Adding
an NAI SHOULD be a trivial change.

> Maybe there needs to be "extension-specific"
> MIB fields for the AAA MIB.  Errr.... is there such a thing
> as an AAA MIB?  How about a Mobile IP extension MIB for AAA?

The AAA Design Team does have DIAMETER MIBs on its plate, and I do agree with
your statement.

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 14:15:54 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16143
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 14:15:53 -0500 (EST)
Received: from standards (47.234.32.16:3355) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF3A8@standards.nortelnetworks.com>; Fri, 3 Nov 2000 13:54:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 72235 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 13:54:08 -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBAF3A6@standards.nortelnetworks.com>; Fri, 3 Nov 2000 13:54:08
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Fri, 03 Nov 2000 11:09:25 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <V9J9TGKD>; Fri, 3 Nov 2000 11:10:06 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA81C9B98@red-msg-06.redmond.corp.microsoft.com>
Date:         Fri, 3 Nov 2000 11:09:45 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> > > When calculating the AH checksum, the mobile node performs
> > > the calculation with all data in place.  This means that,
> > > during the calculation, the Care-of Address might be in the
> > > Source IP address field of the IPv6 header, and then the home
> > > address would be in the Home Address destination option.

This is my preference. Some implementations need to treat packet data as
read-only and can't actually switch or exchange addresses in the packet.

It's really not too hard to pass along a bit of additional data with the
packet, essentially a pointer to the logical source address, which initially
points to the source address in the IPv6 header and later points to the
address in the Home Address option.

> > 3. Process AH naturally. Security Association is chosen
> based on the source
> > address of the packet.

I've seen this opinion in several messages and I don't understand it. When
processing an AH or ESP header, the security association is chosed based on
the *destination* address, the SPI, and the IPsec header type. See section
5.2.1 of RFC 2401.

Therefore, I don't why it's advantageous to process the Home Address option
before the IPsec header. I would appreciate it if someone could explain this
again.

You do need to know the Home Address when consulting the Security Policy
Database, but that would typically happen later. To consult the SPD, you
also need to know the upper-layer protocol (eg TCP or UDP) and port numbers.

Thanks,
Rich


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 15:58:38 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20593
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 15:58:37 -0500 (EST)
Received: from standards (47.234.32.16:1252) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF4F4@standards.nortelnetworks.com>; Fri, 3 Nov 2000 15:40:48 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 72666 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 15:40:47 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBAF4F2@standards.nortelnetworks.com>; Fri, 3 Nov 2000 15:40:47
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA27774;
          Fri, 3 Nov 2000 12:56:46 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA3KuhY30389; Fri, 3 Nov 2000 12:56:43
          -0800
X-Virus-Scanned:  Fri, 3 Nov 2000 12:56:43 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from vijayd.iprg.nokia.com (205.226.2.94,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdh4XsXZ; Fri, 03 Nov 2000
          12:56:38 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <7695E2F6903F7A41961F8CF888D87EA81C9B98@red-msg-06.redmond.corp.microsoft.com>
Content-Type: multipart/mixed; boundary="------------00573E1E33721D9A98A77E9B"
Approved-By:  vijayd@IPRG.NOKIA.COM
Message-ID:  <3A032688.1841FB5@iprg.nokia.com>
Date:         Fri, 3 Nov 2000 12:56:40 -0800
Reply-To: Vijay Devarapalli <vijayd@iprg.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of
              "MobilitySupport
              inIPv6"draft]
X-To:         Richard Draves <richdr@microsoft.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------00573E1E33721D9A98A77E9B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

See my comments below

Richard Draves wrote:

> > > > When calculating the AH checksum, the mobile node performs
> > > > the calculation with all data in place.  This means that,
> > > > during the calculation, the Care-of Address might be in the
> > > > Source IP address field of the IPv6 header, and then the home
> > > > address would be in the Home Address destination option.
>
> This is my preference. Some implementations need to treat packet data as
> read-only and can't actually switch or exchange addresses in the packet.

You never do AH checksum calculation on the original packet. You need
to zero out fields that are mutable. You need to change those fields that
are mutable but predictable. You most often have to create another
mbuf or a text string and calculate the AH checksum on it.

> It's really not too hard to pass along a bit of additional data with the
> packet, essentially a pointer to the logical source address, which initially
> points to the source address in the IPv6 header and later points to the
> address in the Home Address option.

And where would you put such a pointer?

>
> > > 3. Process AH naturally. Security Association is chosen
> > based on the source
> > > address of the packet.
>
> I've seen this opinion in several messages and I don't understand it. When
> processing an AH or ESP header, the security association is chosed based on
> the *destination* address, the SPI, and the IPsec header type. See section
> 5.2.1 of RFC 2401.
>

Look at bullet 2 of section 5.2.1 of RFC 2401.

           2. Use the SA found in (1) to do the IPsec processing, e.g.,
              authenticate and decrypt.  This step includes matching the
              packet's (Inner Header if tunneled) selectors to the
              selectors in the SA.  Local policy determines the
              specificity of the SA selectors (single value, list,
              range, wildcard).  In general, a packet's source address
              MUST match the SA selector value.  However, an ICMP packet
              received on a tunnel mode SA may have a source address.....

SA selection is not finished with step 1. Note the MUST in the above
paragraph. I would be happy if the packet's source address is the
Home address of the mobile node at this point. At this point we
havent reached the SPD lookup yet.

Regards
Vijay

> Therefore, I don't why it's advantageous to process the Home Address option
> before the IPsec header. I would appreciate it if someone could explain this
> again.
>
> You do need to know the Home Address when consulting the Security Policy
> Database, but that would typically happen later. To consult the SPD, you
> also need to know the upper-layer protocol (eg TCP or UDP) and port numbers.
>
> Thanks,
> Rich

--------------00573E1E33721D9A98A77E9B
Content-Type: text/x-vcard; charset=us-ascii;
 name="vijayd.vcf"
Content-Description: Card for Vijay Devarapalli
Content-Disposition: attachment;
 filename="vijayd.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Devarapalli;Vijay
tel;cell:(650) 302 8629
tel;work:(650) 625 2320
x-mozilla-html:FALSE
org:Nokia Research Center
version:2.1
email;internet:vijayd@iprg.nokia.com
title:Research Enginner
adr;quoted-printable:;;313 Fairchild Drive=0D=0A;Mountain View;CA;95051;USA
x-mozilla-cpt:;-12992
fn:Vijay Devarapalli
end:vcard

--------------00573E1E33721D9A98A77E9B--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 16:53:04 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06501
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 16:53:03 -0500 (EST)
Received: from standards (47.234.32.16:1252) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF5C2@standards.nortelnetworks.com>; Fri, 3 Nov 2000 16:35:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 72933 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 16:35:19 -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBAF5C0@standards.nortelnetworks.com>; Fri, 3 Nov 2000 16:35:19
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Fri, 03 Nov 2000 13:30:25 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <V9J94D77>; Fri, 3 Nov 2000 13:31:06 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA81C9B99@red-msg-06.redmond.corp.microsoft.com>
Date:         Fri, 3 Nov 2000 13:30:37 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
X-To:         Mohan Parthasarathy <mohanp@locked.eng.sun.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> In step (2) of section 5.2.1, it does explain "... a packets
> source address
> MUST match the SA selector value". This is explained in
> section 4.4.3 also.
> The above wording is not correct. But one has to do the checks to make
> sure that the right SA was used for this packet. It would be
> nice if the
> IPv6 header's source address field contained the Home Address before
> the IPsec processing begins. Again, this is implementation dependent.
> Some implementations might find it easier to do it this way.

Thanks for helping me understand this. Doesn't the IPsec processing
(checking selectors) need more than just the source address? It needs other
selectors, like the transport protocol & port values. So if you wish to
implement the processing when you see the AH/ESP header, you need to look
ahead in the packet to find these values. This looking ahead could also find
the Home Address. On the other hand, if you delay this processing until you
see the TCP/UDP header, then you'll have already processed an intervening
Home Address option. So either way, having the Home Address option after the
IPsec header doesn't seem too difficult for implementations. What am I
missing?

Thanks,
Rich


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 17:30:33 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15670
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 17:30:32 -0500 (EST)
Received: from standards (47.234.32.16:1252) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF622@standards.nortelnetworks.com>; Fri, 3 Nov 2000 17:12:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 73053 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 17:12:38 -0500
Received: from ish7.ericsson.com.au (203.61.155.111:63171) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBAF620@standards.nortelnetworks.com>; Fri, 3 Nov 2000
          17:12:37 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id JAA06161 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sat, 4 Nov 2000 09:25:25
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id JAA06885 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sat, 4 Nov 2000 09:28:04
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <V42TWA9W>; Sat, 4 Nov 2000 09:28:17 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613D7E@eaubrnt018.epa.ericsson.se>
Date:         Sat, 4 Nov 2000 09:28:16 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> Thanks for helping me understand this. Doesn't the IPsec processing
> (checking selectors) need more than just the source address? It needs
> other
> selectors, like the transport protocol & port values. So if you wish to
> implement the processing when you see the AH/ESP header, you need to look
> ahead in the packet to find these values. This looking ahead could also
> find
> the Home Address. On the other hand, if you delay this processing until
> you
> see the TCP/UDP header,
>
        => How can you see that if you have ESP ? Have I misunderstood
         you ?


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 17:57:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21630
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 17:57:19 -0500 (EST)
Received: from standards (47.234.32.16:1252) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF683@standards.nortelnetworks.com>; Fri, 3 Nov 2000 17:39:27 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 73180 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 17:39:27 -0500
Received: from ish7.ericsson.com.au (203.61.155.111:63327) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBAF681@standards.nortelnetworks.com>; Fri, 3 Nov 2000
          17:39:26 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id JAA06412 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sat, 4 Nov 2000 09:52:13
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id JAA08354 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sat, 4 Nov 2000 09:54:52
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <V42TWBAK>; Sat, 4 Nov 2000 09:37:54 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613D7F@eaubrnt018.epa.ericsson.se>
Date:         Sat, 4 Nov 2000 09:37:53 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hello Dave and Charlie,

On the topic of new version of MIPv6, I'd like to bring up
one possible improvement. DAD !

I think this has been discussed a lot, we talked about it
in Adelaide, Pittsburgh and now it's a hot topic
(as Charlie knows ) in the fast handoffs team.

I don't think DAD is only relevant for fast handoffs.
I believe it is also relevant to the current standard.
As said earlier, with DAD we could be looking at a
2 second delay for the handoff. Certainly unacceptable
for any type of service.

Perhaps we can make some exceptions / suggestions
in the draft to work around some of the strict requirements
in 2462. I realise that most ideas will not be able to provide
us with a fault proof situation, however to avoid
this significant delay maybe we can live with a very
small probability of collision that will be detected shortly
anyway.

So what I have in mind is very simple,

execute handoff,
Get a new COA and use it while doing DAD in parallel.

I certainly see the problems with that. But something needs
to be done. A 2 seconds delay is unacceptable for any service.

Regards
Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 19:41:05 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14260
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 19:41:05 -0500 (EST)
Received: from standards (47.234.32.16:1252) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF75C@standards.nortelnetworks.com>; Fri, 3 Nov 2000 19:23:19 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 73463 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 19:23:18 -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBAF75A@standards.nortelnetworks.com>; Fri, 3 Nov 2000 19:23:17
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Fri, 03 Nov 2000 16:36:58 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <V9J9V11X>; Fri, 3 Nov 2000 16:37:39 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA80130C883@red-msg-06.redmond.corp.microsoft.com>
Date:         Fri, 3 Nov 2000 16:37:25 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
X-To:         Mohan Parthasarathy <mohanp@locked.eng.sun.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> The other argument for having it before the IPsec headers is to
> enable the firewalls to determine the real address.

The other other argument would be, maybe I want to hide my home address from
the network that I'm visiting, and so I want to have the Home Address option
sitting behind an ESP header with encryption. :-)

Rich


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 19:48:12 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15801
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 19:48:11 -0500 (EST)
Received: from standards (47.234.32.16:1252) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF778@standards.nortelnetworks.com>; Fri, 3 Nov 2000 19:25:10 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 73498 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 19:25:08 -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBAF776@standards.nortelnetworks.com>; Fri, 3 Nov 2000 19:25:08
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Fri, 03 Nov 2000 16:31:50 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <V9J9VDP2>; Fri, 3 Nov 2000 16:32:31 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA81C9B9B@red-msg-06.redmond.corp.microsoft.com>
Date:         Fri, 3 Nov 2000 16:32:10 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> > Thanks for helping me understand this. Doesn't the IPsec processing
> > (checking selectors) need more than just the source
> address? It needs
> > other
> > selectors, like the transport protocol & port values. So if
> you wish to
> > implement the processing when you see the AH/ESP header,
> you need to look
> > ahead in the packet to find these values. This looking
> ahead could also
> > find
> > the Home Address. On the other hand, if you delay this
> processing until
> > you
> > see the TCP/UDP header,
> >
>         => How can you see that if you have ESP ? Have I misunderstood
>          you ?

I hope so :-). When processing the ESP header, you'd use the destination
address, SPI, and IPsec header type to find the SA and decrypt the remainder
of the packet. Then to implement the required selector checks, you could
either scan ahead in the packet to find the transport header and look for a
home address option, or you could delay the selector checks until you
actually process the transport header.

As I understand it, the reasoning has been:
- some implementations find it convenient to know the home address when
processing the IPsec header
- therefore it would be convenient if the Home Address option appears before
the IPsec header
- but the Home Address option (and care-of address in the IPv6 header) needs
to be protected to process a Binding Update
- therefore the Binding Update MUST be protected by AH.

So we've gone from a matter of convenience for some implementations (which
seems minor to me, as I've described above) to a real limitation in Mobile
IPv6. If I want to encrypt my traffic, this means I have to use AH in
addition to ESP.

The alternative is to allow the Home Address and Binding Update (with a
Care-Of Address suboption) to appear after an ESP header. Why isn't this a
viable alternative that should be allowed?

Thanks,
Rich


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 20:07:37 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20018
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 20:07:36 -0500 (EST)
Received: from standards (47.234.32.16:2591) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF7F8@standards.nortelnetworks.com>; Fri, 3 Nov 2000 19:49:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 73664 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 19:49:49 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBAF7F6@standards.nortelnetworks.com>; Fri, 3 Nov 2000 19:49:48
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA21251;
          Fri, 3 Nov 2000 17:05:48 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA415kn12812; Fri, 3 Nov 2000 17:05:46
          -0800
X-Virus-Scanned:  Fri, 3 Nov 2000 17:05:46 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from Icharliep-1.iprg.nokia.com (205.226.22.18,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdBuShuY; Fri, 03 Nov 2000
          17:05:41 PST
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Charlie Perkins <charliep@IPRG.NOKIA.COM>
Message-ID:  <3A036088.DE8D294D@iprg.nokia.com>
Date:         Fri, 3 Nov 2000 17:04:08 -0800
Reply-To: Charlie Perkins <charliep@iprg.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Charlie Perkins <charliep@iprg.nokia.com>
Organization: Nokia
Subject:      [MOBILE-IP] How Mobile IPv6 should handle home network renumbering
X-To:         IPng Working Group <ipng@sunroof.eng.sun.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello everyone,

I'm forwarding to these lists some text supplied by Ken
Powell for updating relevant sections of the Mobile IPv6
draft.  I find that Ken's proposed modifications are
quite reasonable and answer many outstanding open issues.
In subsequent messages, I will elaborate on some details
about _when_ a home agent should send new prefix information
to the mobile node.  However, I thought it would be easiest
to reproduce Ken's original message in its entirety, so as
not to disrupt a very coherent presentation.

Regards,
Charlie P.

PS. It's taken me a week to study the material in Ken's
    message, as well as related messages from other people.
    Sorry for the additional delay.

-------- Original Message --------
Date: Fri, 3 Nov 2000 13:05:40 -0800 (PST)
From: Charles Perkins <charliep@iprg.nokia.com>
To: charliep@iprg.nokia.com

From:   Powell, Ken
Sent:   Friday, October 27, 2000 5:05 PM
To:     'charliep@iprq.nokia.com'
Cc:     'dbj@cs.cmu.edu'; Bound, Jim
Subject:        Mobile IPv6 contributions

Hi Charlie,

A few weeks ago you asked if I could provide any text for
the Mobile IPv6 Spec regarding the issues we discussed.
I apologize for the delay, but hope the following may still
be relevant to your planned changes. The areas covered are:

  1) How the home agent constructs an aggregate list
     of prefixes advertised by other routers on the
     home network.

  2) What triggers a home agent to send router
     advertisements to a mobile node, and what
     prefixes should be included in each advertisement.
     I primarily added aggregate list references and
     periodic transmission of all prefixes to the
     existing text. I believe you also mentioned
     using binding updates as a mechanism to rate-
     limit Router Advertisements, so I added that too.

  3) When and how to send a router solicitation from
     a mobile node to the home agent.

  4) How to receive a router solicitation from
     a mobile node to the home agent.

One other thought, my text uses a new configuration
variable to control the timing of periodic router
advertisements to mobile nodes called MobileRtrAdvInterval.
Such a variable could reasonably default to a relatively
long period of time, like an hour or more, but otherwise
work much like MaxRtrAdvInterval in the ND spec. I wasn't
sure how to introduce this.

I hope this text is helpful. Feel free to use, rewrite, cut,
as it makes sense. You're also welcome to forward this off to
the ipng or mobilip mailing lists if you like. Let me know
if you have any questions/concerns.

Ken


Item 1 (perhaps add into section 9.7)
=====================================

A mobile node on a remote network should autoconfigure the
same set of home addresses it would autoconfigure if it
were attached to the home network. To support this, the
home agent monitors prefixes advertised by other routers
on the home subnet and passes the aggregate list of
home subnet prefixes on to the mobile node in Router
Advertisements.

The home agent SHOULD construct the aggregate list of home
subnet prefixes as follows:

  o Copy prefix information defined in the home agent's
    AdvPrefixList on the home subnet's interfaces to the
    aggregate list. Also apply any changes made to the
    AdvPrefixList on the home agent to the aggregate list.

  o Check valid prefixes received in Router Advertisements
    from the home network for consistency with the home
    agent's AdvPrefixList per section 6.2.7 of RFC 2461 (ND).
    Do not update the aggregate list with any information
    from received prefixes that fail this check.

  o Add valid prefixes received in Router Advertisements
    from the home network that are not yet in the aggregate
    list to the aggregate list along with the value of their
    L and A flags. Clear the R flag and zero the interface
    id portion of the prefix field to prevent mobile
    nodes from treating another router's interface address
    as belonging to the home agent. Treat the lifetimes
    of these prefixes as "deprecating".

  o Do not perform consistency checks on valid prefixes
    received in Router Advertisements on the home network
    that do not exist in the home agent's AdvPrefixList.
    Instead, if the prefixes already exist in the aggregate
    list, update the prefix lifetime fields in the aggregate
    list according to the rules specified for hosts in
    section 6.3.4 of RFC 2461 (ND) and section 5.5.3 of
    RFC 2462 (stateless adderconf).

  o If the L or A flag is set on valid prefixes received in
    a Router Advertisement, and that prefix already exists
    in the aggregate list, set the corresponding flag in
    the aggregate list. Ignore the received L or A flag if
    it is clear.

  o Ignore the R flag and interface id portion of any
    prefix received in a Router Advertisement.

  o Delete prefixes from the aggregate list when
    their valid lifetimes expire. (***Did the
    group agree to keep advertising these prefixes
    for a period of time with a zero lifetime? **)


Item 2 (perhaps replace similar text in section 9.7)
====================================================

A home agent serving a mobile node SHOULD construct and
tunnel to the mobile node a new Router Advertisement when
any of the following conditions occur:

  o A valid or preferred lifetime of a prefix in the
    aggregate list of prefixes is suddenly reduced to
    less than HomeRtrAdvInterval.

  o The state of the flags for a prefix in the aggregate
    list changes.

  o A new prefix is created in the aggregate list.

The home agent constructs a new Router Advertisement message
containing no options other than the Prefix Information options
describing the prefixes for which one of the conditions above
has occurred since the last Router Advertisement tunneled to and
acknowledged by the mobile node.

In addition, the home agent MUST send a router advertisement
with all prefixes in the aggregate list to the mobile node at
least once per HomeRtrAdvInterval and upon receipt of a valid
Router Solicitation from the mobile node.

The home agent MAY (SHOULD?) rate limit the frequency at which it
sends Router Advertisements to the mobile node by delaying transmission
until receipt of a Binding Update option from the mobile node.
When multiple conditions occur at or near the same time, the
home agent SHOULD attempt to combine them into a single Router
Advertisement message to the mobile node.

Item 3
======

10.x Sending Router Solicitations to a Home Agent

A mobile node that uses stateless address auto configuration on
its home subnet could miss significant home subnet configuration
changes while disconnected. Such a mobile node MAY request updated
prefix information when it detects a possibility that its current
home subnet address information is inaccurate by sending a Router
Solicitation to the home agent. The mobile node must construct
such a Router Solicitation packet as follows:

 -  The Source Address in the packet's IPv6 header MUST be set
    to the mobile node's primary care-of address.

 -  The packet MUST be protected by IPsec [13, 11, 12] to guard
    against malicious Router Solicitations.  The IPsec protection
    MUST provide sender authentication, data integrity protection,
    and replay protection, covering the Router Solicitation.

 - The packet MUST include a Home Address destination option,
   giving the mobile node's home address for its current
   binding.

 - The packet MUST include a Binding Update destination option
   as described in section 10.6 if a current binding does not
   yet exist. Otherwise, it MAY include a Binding Update
   destination option.

 - The Router Solicitation's source link-layer address
   option MUST be omitted.

Item 4
======

6.x Receiving Router Solicitations from Mobile Nodes

Section xx describes how a mobile node on a remote network
may send a Router Solicitation to a home agent to request
all current address prefix information on the home subnet.

The Router Solicitation may include a Binding Update
destination option. The processing requirements described
here for the Router Solicitation assume the Binding Update
destination option was processed first. The home agent MAY
return a single packet containing both the resulting Binding
Acknowledgment destination option and a Router Advertisement.

When a home agent receives a Router Solicitation from a mobile
node on a remote network, it MUST validate it according to the
following tests:

 - A home registration binding cache entry exists for the
   mobile node.

 - The Source Address of the IP packet carrying the Router
   Solicitation is the same as the primary care-of address
   for the mobile node.

 - The Home Address destination option contains the same
   address as the home address specified in the binding cache
   entry for the mobile node.

 - The packet is protected by IPsec [13, 11, 12] to guard
   against malicious Router Advertisements.  The IPsec protection
   provides sender authentication, data integrity protection,
   and replay protection, covering the Router Advertisement.

Any received tunneled Router Solicitation not meeting all of
these tests MUST be silently discarded.

If a received tunneled Router Solicitation is not discarded
according to the tests listed above, the home agent MUST
generate and tunnel to the mobile node as described in
section 6.7 a set of Router Advertisement(s) which combined
contain all entries in the aggregate list of prefixes for
the mobile node's home network.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov  3 20:43:38 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27830
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Nov 2000 20:43:37 -0500 (EST)
Received: from standards (47.234.32.16:2591) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF867@standards.nortelnetworks.com>; Fri, 3 Nov 2000 20:25:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 73807 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 20:25:44 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBAF865@standards.nortelnetworks.com>; Fri, 3 Nov 2000 20:25:44
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA23721
          for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 3 Nov 2000
          17:41:43 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA41fdA09186 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 3 Nov 2000 17:41:39
          -0800
X-Virus-Scanned:  Fri, 3 Nov 2000 17:41:39 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from Icharliep-1.iprg.nokia.com (205.226.22.18,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdLTIFVt; Fri, 03 Nov 2000
          17:41:35 PST
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <3A036088.DE8D294D@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Charlie Perkins <charliep@IPRG.NOKIA.COM>
Message-ID:  <3A0368F3.5C3C4432@iprg.nokia.com>
Date:         Fri, 3 Nov 2000 17:40:03 -0800
Reply-To: Charlie Perkins <charliep@iprg.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Charlie Perkins <charliep@iprg.nokia.com>
Organization: Nokia
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home network
              renumbering
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello again,

In Ken's note, a proposal is made for how the home agent
should forward relevant router advertisement information to
the mobile node, when the mobile node is away from its
home network.

I have devised an algorithm by which a home agent can
delay the transmission of this information to the mobile
node, in hopes that the actual transmission can be avoided
entirely if the mobile node might send a Binding Update
to the home agent.  In that case, the home agent could
include all the relevant information in the Binding
Acknowledgement.

Item 2 is "What triggers a home agent to send router"

Ken suggested:

> Item 2 (perhaps replace similar text in section 9.7)
> ====================================================
>
> A home agent serving a mobile node SHOULD construct and
> tunnel to the mobile node a new Router Advertisement when
> any of the following conditions occur:
>
>   o A valid or preferred lifetime of a prefix in the
>     aggregate list of prefixes is suddenly reduced to
>     less than HomeRtrAdvInterval.
>
>   o The state of the flags for a prefix in the aggregate
>     list changes.
>
>   o A new prefix is created in the aggregate list.
>
> The home agent constructs a new Router Advertisement message
> containing no options other than the Prefix Information options
> describing the prefixes for which one of the conditions above
> has occurred since the last Router Advertisement tunneled to and
> acknowledged by the mobile node.
>
> In addition, the home agent MUST send a router advertisement
> with all prefixes in the aggregate list to the mobile node at
> least once per HomeRtrAdvInterval and upon receipt of a valid
> Router Solicitation from the mobile node.
>
> The home agent MAY (SHOULD?) rate limit the frequency at which it
> sends Router Advertisements to the mobile node by delaying transmission
> until receipt of a Binding Update option from the mobile node.
> When multiple conditions occur at or near the same time, the
> home agent SHOULD attempt to combine them into a single Router
> Advertisement message to the mobile node.

Instead of a specific rate-limiting feature, I suggest the following
algorithm:

===== How to send router advertisements to mobile nodes.

- If a mobile node sends a solicitation, answer with everything.

- If a prefix changes state in a way that causes a mobile node's
  address to go deprecated, send an advertisement right away.

- If the mobile node's binding expires before the advertised
  Preferred Lifetime, do not schedule the advertisement.
  The mobile node will get the revised information in its next
  Binding Acknowledgement.

- If a prefix is added, or if it changes in any way that does not
  cause the mobile node's address to go deprecated, ensure that
  a transmission is scheduled at time RAND_ADV_DELAY in the future.

- If a prefix advertisement is scheduled, and a Binding
  Update arrives, perform that advertisement and include
  the information in a Router Advertisement that has the
  Binding Acknowledgement as a Destination Option.  Remove
  the future scheduled advertisement.

===== How to compute RAND_ADV_DELAY, the offset from the
      current time for the scheduled transmission

If there is a transmission already scheduled, then
 if the current RAND_ADV_DELAY would cause another
 transmission BEFORE the Preferred Lifetime of the
 mobile node's home address derived from the prefix
 whose advertisement information has changed, then
               add the new information to be transmitted
               to the existing scheduled transmission
               -- return.
          otherwise,
               continue with the following computation,
               and add the data from the existing scheduled
               transmission to the newly scheduled transmission,
              deleting the previously scheduled transmission
               event.

If the mobile node's binding expires after the Preferred
Lifetime, then compute
           MAX_SCHEDULE_DELAY ==
                     min (MAX_PFX_ADV_DELAY, Preferred Lifetime)
for the newly advertised Preferred Lifetime.
Then compute RAND_ADV_DELAY =
             MinRtrAdvInt + rand()*{MAX_SCHEDULE_DELAY - MinRtrAdvInt}

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

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Nov  4 06:10:21 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA24381
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 4 Nov 2000 06:10:20 -0500 (EST)
Received: from standards (47.234.32.16:2020) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAFAA6@standards.nortelnetworks.com>; Sat, 4 Nov 2000 5:52:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 74556 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 4 Nov 2000 05:52:05 -0500
Received: from flower.comeng.chungnam.ac.kr by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBAFAA4@standards.nortelnetworks.com>; Sat, 4 Nov 2000 5:51:59
          -0500
Received: from Beethoven (Beethoven.comeng.chungnam.ac.kr [168.188.46.199]) by
          flower.comeng.chungnam.ac.kr (8.9.1/8.9.1) with SMTP id UAA01721 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sat, 4 Nov 2000 20:02:22
          +0900 (KST)
References: <00a601c0445d$d6c11800$c72ebca8@ce.cnu.ac.kr>          
            <3A010205.D5D2D68D@iprg.nokia.com>          
            <004001c04496$de125360$c72ebca8@ce.cnu.ac.kr>          
            <3A01D2B3.AD5C6E71@iprg.nokia.com>          
            <01ae01c04548$7f6bb1a0$c72ebca8@ce.cnu.ac.kr> 
            <3A02EB55.3C7205C5@iprg.nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Approved-By:  "Park, Hyun Seo" <hspark@CE.CNU.AC.KR>
Message-ID:  <005101c0464f$752b3320$c72ebca8@ce.cnu.ac.kr>
Date:         Sat, 4 Nov 2000 20:07:40 +0900
Reply-To: "Park, Hyun Seo" <hspark@ce.cnu.ac.kr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Park, Hyun Seo" <hspark@ce.cnu.ac.kr>
Subject:      Re: [MOBILE-IP] Question about "Route Optimization in Mobile IP"
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id GAA24381

Hello Charlie,

> Hello Park,
> 
> > [Park] Then, when CN receives "Binding Warning", what can CN do ?
> >     In present Route Optimization draft, when a Node, that is, HA receives
> >     "Binding Warning", it sends "Binding Update" to the target node in
> >     "Binding Warning" message ... Please explain to me in detail ...
> 
> The Correspondent Node should delete its binding for the mobile
> node.  Then packets will go to the home network.  Then the home
> agent will send a Binding Update, or else the mobile node will.

Do you mean another use of "Binding Warning" ?
When a HA receives "Binding Warning", 
    it should send "Binding Update" to the target node in "Binding Warning" ...
When a CN receives "Binding Warning",
    it should delete "Binding Cache" ...
I think it is a little unreasonable .... 
How about my approach that is, "Binding Cache" for "Deregistered MN" ?
I think it is more logical ... 

> >> Besides, the Previous Foreign Agent Notification (PFAN) is supposed
> >> to supply a binding with a nonzero lifetime to the previous foreign
> >> agent.  If the home agent is the agent that issues the PFAN message,
> >> then it should still not have a nonzero lifetime.
> >
> > [Park] In My Opinion, I do not think PFAN can not be used with nonzero
> >     lifetime ....  HA can send "Binding Update" with a zero lifetime ...
> >     Similarly, when HA receives PFAN with zero lifetime,
> >     it can send "Binding Update" with a zero lifetime to Old FA ...
> 
> O.K. with me.  Why would the home agent get a PFAN with zero lifetime?

For "Smooth Handoff" ...
When MN returns Home Network from Foreign Network,
    it can send "Registration Request" (Deregistration) with attached PFAN Ext. with zero lifetime ....

> >> It is good that you pointed this out, and we should make it explicit in
> >> the text. I would rather set things up in this way, to be consistent with
> >> roaming between foreign agents, than to introduce yet another timing
> >> dependency with static timing parameters.
> >
> > [Park] What is "timing dependency with static timing parameters" ?
> >     Perhaps I am missing something .. Please let me know ...
> >     Thanks a lot, Charlie ...
> 
> I was trying to imagine how a mobile agent would know when to delete
> its entry for this:

I think There is no serious problem even if a mobile agent does not delete "Binding Cache"
for "Deregistered MN" ...
If "Deregistered MN" moves another Foreign Network again,
    that mobile agent can get "Binding Update" from HA after one or some packets ...  
Then that mobile agent can update its "Binding Cache" ...
An alternative is a use of "Default Lifetime" for "Deregistered MN" ...

> 
> > [Park] How about "Binding Cache for Deregistered MN" ?
> >     When any node receives "Binding Update" with <COA = MN's Home Address,
> >     Lifetime = 0>, it creates no "Binding Cache" and deletes existing
> >     "Binding Cache" or "Visitor List" for that MN ....
> >
> >     But, when FA receives "Binding Update" for deregistered MN from HA,
> >     it makes a "Binding Cache" for MN with <COA = NULL or MN's Home Address
> >     Then, when FA receives tunneled datagrams to MN from any node,
> >     it re-routes them to MN's Home Network and sends "Binding Warning"
> >      to MN's HA ...     How about it ?
> 
> What would you suggest other than some preconfigured static timing
> parameter, indicated either by the home agent or the foreign agent?
> 
> Regards,
> Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Nov  4 10:32:24 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02785
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 4 Nov 2000 10:32:23 -0500 (EST)
Received: from standards (47.234.32.16:4357) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAFBC4@standards.nortelnetworks.com>; Sat, 4 Nov 2000 10:14:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 74959 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 4 Nov 2000 10:14:21 -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBAFBC2@standards.nortelnetworks.com>; Sat, 4 Nov 2000 10:14:20
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eA4FUDb35881; Sat, 4 Nov 2000 16:30:13 +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 QAA17516; Sat, 4 Nov 2000 16:30:12 +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.9.3/8.9.3) with
          ESMTP id QAA65425; Sat, 4 Nov 2000 16:31:20 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011041531.QAA65425@givry.rennes.enst-bretagne.fr>
Date:         Sat, 4 Nov 2000 16:31:20 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
X-To:         Richard Draves <richdr@microsoft.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Fri, 03 Nov 2000 11:09:45 PST. 
              <7695E2F6903F7A41961F8CF888D87EA81C9B98@red-msg-06.redmond.corp.microsoft.com>

 In your previous mail you wrote:

   > > > When calculating the AH checksum, the mobile node performs
   > > > the calculation with all data in place.  This means that,
   > > > during the calculation, the Care-of Address might be in the
   > > > Source IP address field of the IPv6 header, and then the home
   > > > address would be in the Home Address destination option.

   This is my preference. Some implementations need to treat packet data as
   read-only and can't actually switch or exchange addresses in the packet.

=> it is really a matter of taste... As far as I know nobody strongly objects
against a solution or the other.

   > > 3. Process AH naturally. Security Association is chosen
   > based on the source
   > > address of the packet.

   I've seen this opinion in several messages and I don't understand it. When
   processing an AH or ESP header, the security association is chosed based on
   the *destination* address, the SPI, and the IPsec header type. See section
   5.2.1 of RFC 2401.

=> I agree the inbound SA lookup uses only this triple (with the receiving
interface for scoped IPv6 destination address but we can say the zone is
a property of the address, ie. it is just a pitfall for implementors :-).
But it is not true for the outbound processing and SAs have a source
address (clear in IKE specs) and maybe a proxy address (cf PF_KEY).
These addresses can be checked by the inbound code:
 - no check
 - check before processing (paranoia?)
 - check after processing
I know KAME doesn't check the source address and OpenBSD checks it after
processing (and check the inner source with the proxy address for tunnels).
Old NRL code checks it with the found SA source and proxy addresses in
the lookup routine... The three options are present in the first three
implementations have looked for!

Then for paranoid IPsec implementations the home address should be before
the IPsec headers and for firewalls (paranoid by definition :-) it should
be available in clear text in all packets, including fragments.

   Therefore, I don't why it's advantageous to process the Home Address option
   before the IPsec header. I would appreciate it if someone could explain this
   again.

=> it makes paranoid IPsec correspondent (ie. at receiving side)
implementations easy to implement and it makes firewall people happy.

   You do need to know the Home Address when consulting the Security Policy
   Database, but that would typically happen later. To consult the SPD, you
   also need to know the upper-layer protocol (eg TCP or UDP) and port numbers.

=> I agree. This argument (SPD will check anyway) can be used if you'd like
to banish paranoid IPsec implementations... I believe to check the source
address in the SA processing is too restrictive (I've got some comments
about my I-D for home tunnels because of this :-) then I'll support you?

Note that to have a source address in a SA is still useful (our concern
is about a bad? usage of it), IKE builds a pair of SAs and the source
of one SA is the destination of the other. For mobile IPv6 SAs are
between the home agent (with its unicast address known/used by the mobile)
and the mobile node (with its home *stable* address). If the second
address is wrong BAs will be wrong.

Regards

Francis.Dupont@enst-bretagne.fr

PS: the good news is this works (we did a secure BU/BA exchange at the ETSI
bake-off), the bad news is you need (to be) an IPsec expert in order to
make this work... IKE configuration for instance is a nightmare.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Nov  4 11:19:49 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21959
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 4 Nov 2000 11:19:48 -0500 (EST)
Received: from standards (47.234.32.16:2791) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAFC27@standards.nortelnetworks.com>; Sat, 4 Nov 2000 11:01:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 75087 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 4 Nov 2000 11:01:59 -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBAFC25@standards.nortelnetworks.com>; Sat, 4 Nov 2000 11:01:58
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eA4GHub34173; Sat, 4 Nov 2000 17:17:57 +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 RAA18454; Sat, 4 Nov 2000 17:17:56 +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.9.3/8.9.3) with
          ESMTP id RAA65573; Sat, 4 Nov 2000 17:19:05 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011041619.RAA65573@givry.rennes.enst-bretagne.fr>
Date:         Sat, 4 Nov 2000 17:19:04 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of
              "MobilitySupport
              inIPv6"draft]
X-To:         Vijay Devarapalli <vijayd@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Fri, 03 Nov 2000 12:56:40 PST. 
              <3A032688.1841FB5@iprg.nokia.com>

 In your previous mail you wrote:

   > > > 3. Process AH naturally. Security Association is chosen
   > > based on the source
   > > > address of the packet.
   >
   > I've seen this opinion in several messages and I don't understand it. When
   > processing an AH or ESP header, the security association is chosed based on
   > the *destination* address, the SPI, and the IPsec header type. See section
   > 5.2.1 of RFC 2401.
   >

   Look at bullet 2 of section 5.2.1 of RFC 2401.

              2. Use the SA found in (1) to do the IPsec processing, e.g.,
                 authenticate and decrypt.  This step includes matching the
                 packet's (Inner Header if tunneled) selectors to the
                 selectors in the SA.  Local policy determines the
                 specificity of the SA selectors (single value, list,
                 range, wildcard).  In general, a packet's source address
                 MUST match the SA selector value.  However, an ICMP packet
                 received on a tunnel mode SA may have a source address.....

   SA selection is not finished with step 1. Note the MUST in the above
   paragraph.

=> I don't know exactly how to deal with this MUST (introduced by
a "in general" ???). The source address of the packet with the IPsec
header is or:
 - explicitely protected by AH
 - implicitely protected by the successfull processing according to
   the SA (ie. one can't impersonate the real source because it doesn't
   know shared secret(s))
then it is clearly for tunneled packets because it applies to the
*inner* source address (1). Note the text doesn't give the name of the SA
selector, according to RFC 2401 or RFC 2409 it is "source", according to
RFC 2367 it is "proxy" and in RFC 2409 there is a (not) clarification
about "acting as a client negotiator on behalf of another party"...

   I would be happy if the packet's source address is the
   Home address of the mobile node at this point.

=> even if the check is based on a misinterpretation of RFC 2401
I agree with you that we need the home address there in the real world!

   At this point we havent reached the SPD lookup yet.

=> SPD processing is clearer because it is only on the inner header.

Regards

Francis.Dupont@enst-bretagne.fr

PS 1: the quoted packet's source address is the inner one because at
the head of the enumeration there is: "Note that the selector checks
are made on the inner headers not the outer (tunnel) headers."


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Nov  4 12:27:56 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15571
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 4 Nov 2000 12:27:56 -0500 (EST)
Received: from standards (47.234.32.16:1380) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAFCB0@standards.nortelnetworks.com>; Sat, 4 Nov 2000 12:10:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 75267 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 4 Nov 2000 12:10:03 -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBAFCAE@standards.nortelnetworks.com>; Sat, 4 Nov 2000 12:10:03
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eA4HQ1b31332; Sat, 4 Nov 2000 18:26:02 +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 SAA19842; Sat, 4 Nov 2000 18:26:01 +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.9.3/8.9.3) with
          ESMTP id SAA65983; Sat, 4 Nov 2000 18:27:09 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011041727.SAA65983@givry.rennes.enst-bretagne.fr>
Date:         Sat, 4 Nov 2000 18:27:09 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
X-To:         Richard Draves <richdr@microsoft.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Fri, 03 Nov 2000 16:37:25 PST. 
              <7695E2F6903F7A41961F8CF888D87EA80130C883@red-msg-06.redmond.corp.microsoft.com>

 In your previous mail you wrote:

   > The other argument for having it before the IPsec headers is to
   > enable the firewalls to determine the real address.

   The other other argument would be, maybe I want to hide my home address from
   the network that I'm visiting, and so I want to have the Home Address option
   sitting behind an ESP header with encryption. :-)

=> if you'd like to hide your home address then you can't send binding
updates to correspondents (because the home address will be in the routing
header)... then I think you need more a tunnel configuration tool (ESP in
tunnel mode will be better suited, ie. I propose a two-way IPsec tunnel
between the mobile and the home agent/security gateway) than mobility.

Of course, simple way to update your outer source address after a movement
won't work (or be not so simple) if this address is blindly checked...
And the configuration tool doesn't seem to be ready?

Thanks

Francis.Dupont@enst-bretagne.fr

PS: if you don't really move (ie. be nomadic and not mobile) then a tunnel
broker or a well configurated IKE will do the job.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Nov  4 12:45:09 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19419
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 4 Nov 2000 12:45:08 -0500 (EST)
Received: from standards (47.234.32.16:1380) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAFCFE@standards.nortelnetworks.com>; Sat, 4 Nov 2000 12:27:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 75366 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 4 Nov 2000 12:27:19 -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBAFCFB@standards.nortelnetworks.com>; Sat, 4 Nov 2000 12:27:19
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eA4HhCb24315; Sat, 4 Nov 2000 18:43: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 SAA20204; Sat, 4 Nov 2000 18: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.9.3/8.9.3) with
          ESMTP id SAA66026; Sat, 4 Nov 2000 18:44:20 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011041744.SAA66026@givry.rennes.enst-bretagne.fr>
Date:         Sat, 4 Nov 2000 18:44:20 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Sat, 04 Nov 2000 09:37:53 +1100. 
              <4B6BC00CD15FD2119E5F0008C7A419A50C613D7F@eaubrnt018.epa.ericsson.se>

 In your previous mail you wrote:

   On the topic of new version of MIPv6, I'd like to bring up
   one possible improvement. DAD !

=> this issue really depends on the type of the links which
are used then PLEASE give the context to us!

   I don't think DAD is only relevant for fast handoffs.
   I believe it is also relevant to the current standard.
   As said earlier, with DAD we could be looking at a
   2 second delay for the handoff. Certainly unacceptable
   for any type of service.

=> I disagree! If it takes some seconds to be attached to the link then
DAD is no more an issue. And if you believe a 2 second delay is very
high then you should ask for fast boot for every devices (routers,
computers running fatware OSs, ...).

   So what I have in mind is very simple,

   execute handoff,

=> how the handoff is detected is very important: in many cases
you still use the old COA on the new link just because you don't
know it is a new one.

   Get a new COA and use it while doing DAD in parallel.

=> in the previous context to do DAD just detects the problem
which can't be avoid then it is reasonnable (or the whole case
is not).

   I certainly see the problems with that. But something needs
   to be done. A 2 seconds delay is unacceptable for any service.

=> a simple(r|st) solution is to use only point-to-point links
where IPv6CP (or a similar tool) will do the DAD for free. This is
why the context is important!

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Nov  4 17:59:07 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26494
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 4 Nov 2000 17:59:06 -0500 (EST)
Received: from standards (47.234.32.16:2096) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAFDE0@standards.nortelnetworks.com>; Sat, 4 Nov 2000 17:41:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 75669 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 4 Nov 2000 17:41:13 -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBAFDDE@standards.nortelnetworks.com>; Sat, 4 Nov 2000 17:41:13
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Sat, 04 Nov 2000 14:56:19 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <V9J9YAJD>; Sat, 4 Nov 2000 14:46:42 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA8011ABBFA@red-msg-06.redmond.corp.microsoft.com>
Date:         Sat, 4 Nov 2000 14:46:38 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
X-To:         Mohan Parthasarathy <mohanp@locked.eng.sun.com>,
              Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> AH protects both the care of address and the home address. If
> you use ESP with
> auth you will be protecting the Home address and not the care
> of address.

As I noted in my previous message, the solution is to use a care-of-address
suboption in the Binding Update when using ESP.

>    This is my preference. Some implementations need to treat
> packet data as
>    read-only and can't actually switch or exchange addresses
> in the packet.
>
> => it is really a matter of taste... As far as I know nobody
> strongly objects
> against a solution or the other.

I think I agree with this. Each solution might have efficiency advantages
for one implementation or another, but I don't see a real functionality
difference. (Unlike the issue of MUST use AH, which is real functional
limitation.)

>    The other other argument would be, maybe I want to hide my
> home address from
>    the network that I'm visiting, and so I want to have the
> Home Address option
>    sitting behind an ESP header with encryption. :-)
>
> => if you'd like to hide your home address then you can't send binding
> updates to correspondents (because the home address will be
> in the routing
> header)...

Hence my smiley. You can't even put the routing header behind the ESP
header, because then when the ESP header is processed the destination
address is the care-of address, and you want the SA to be associated with
the home address so you don't have to change SAs when you move.

Rich


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Nov  4 22:06:57 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23836
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 4 Nov 2000 22:06:56 -0500 (EST)
Received: from standards (47.234.32.16:1700) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAFE88@standards.nortelnetworks.com>; Sat, 4 Nov 2000 21:49:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 75893 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 4 Nov 2000 21:49:03 -0500
Received: from ish7.ericsson.com.au (203.61.155.111:39089) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBAFE86@standards.nortelnetworks.com>; Sat, 4 Nov 2000
          21:49:01 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA18916; Sun, 5
          Nov 2000 14:01:51 +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA01802; Sun, 5
          Nov 2000 14:04:29 +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <V42TWHMW>; Sun, 5 Nov 2000 14:04:42 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613D85@eaubrnt018.epa.ericsson.se>
Date:         Sun, 5 Nov 2000 14:04:41 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
X-To:         Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>    On the topic of new version of MIPv6, I'd like to bring up
>    one possible improvement. DAD !
>
> => this issue really depends on the type of the links which
> are used then PLEASE give the context to us!
>
        => Which context is RFC 2462 written into ?
        I'm referring to links that use DAD I don't see a
        need to refer to "a" link type.
        If your link does not use DAD or uses PPP ...etc
        then you do not need to worry about this.
        But if you're running 802.11 for example then
        you probably will use DAD.
        Stateless autoconfiguration and MIPv6 are independant
        of the underlying layers.

>    I don't think DAD is only relevant for fast handoffs.
>    I believe it is also relevant to the current standard.
>    As said earlier, with DAD we could be looking at a
>    2 second delay for the handoff. Certainly unacceptable
>    for any type of service.
>
> => I disagree! If it takes some seconds to be attached to the link then
> DAD is no more an issue.
>
        => Sure, but what if it doesn't take that long ?

>  And if you believe a 2 second delay is very
> high then you should ask for fast boot for every devices (routers,
> computers running fatware OSs, ...).
>
        => I don't see the analogy here. I'm talking about
        a delay every time you do a handoff.

>    So what I have in mind is very simple,
>
>    execute handoff,
>
> => how the handoff is detected is very important: in many cases
> you still use the old COA on the new link just because you don't
> know it is a new one.
>
        => That's a separate issue. I'm talking about the case
        when you know that you moved. That's what I meant
        by "execute handoff" above.
        The bottom line is you don't know that you moved
        (on L3) unless you get a new RA and you lose your
        reachability to your old default router. When that happens
        and you get a new COA then you need to follow RFC
        2462. Hence the delays. There is an interworking
        problem between the 2 standards clearly.
>
> => a simple(r|st) solution is to use only point-to-point links
> where IPv6CP (or a similar tool) will do the DAD for free. This is
> why the context is important!
>
        => This is one scenario. Clearly we can't enforce that in all cases.
         Therefore the context is, the use of stateless autoconfiguration
         and MIPv6 on links that do not provide DAD for free.
        Of course if the network doesn't need DAD then it's not an issue.

        Regards,
        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Nov  5 06:45:45 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02430
	for <mobileip-archive@LISTS.IETF.ORG>; Sun, 5 Nov 2000 06:45:44 -0500 (EST)
Received: from standards (47.234.32.16:2354) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAFF7E@standards.nortelnetworks.com>; 5 Nov 2000 6:27:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 76202 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 5 Nov 2000 06:27:27 -0500
Received: from cbin2-mail.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBAFF7C@standards.nortelnetworks.com>; 5 Nov 2000 6:27:20 -0500
Received: from cisco.com ([64.104.134.105]) by cbin2-mail.cisco.com
          (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA04796; Sun, 5 Nov
          2000 17:12:09 +0530 (IST)
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <3A02D145.729B2D94@cisco.com> <3A02DA83.C0DDB8C7@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Ravindra Rathi <rathi@CISCO.COM>
Message-ID:  <3A05473E.C35B6F65@cisco.com>
Date:         Sun, 5 Nov 2000 17:10:47 +0530
Reply-To: Ravindra Rathi <rathi@cisco.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ravindra Rathi <rathi@cisco.com>
Subject:      Re: [MOBILE-IP] RFC-2006 MIB upgrade is required
X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Charlie,
        I will explain my point by taking specfic examples of few tables in
MIB.

1. haCounterTable
-------------------
 Description of table says  "A table containing registration statistics for
all
 mobile nodes authorized to use this home agent."
            If mobile node (MN) dynamically gets ipaddress based on NAI, then
there can be more that one entry in the table for the same MN since it is
indexed by home address of MN which can change across registrations.
Essentially in that case information in this table would not reflect
statistics for given MN correctly.

2. mipSecViolationTable
-------------------------
            If there is a security violation from one of the MNs which uses
NAI, then
there will be entry in this table with index being ipaddress of MN.  There can
be two problems here.
    i ) MN might not have got ipaddress yet.
   ii)   The entry  can't really identify the  MN since the  ipaddress is not
tied to particular MN.


3. mipSecAssocTable
----------------------
            Security associations between MNs (which are based on NAI ) and
home agent or  foreign agent  can't be retrieved through this table.

--Rathi


"Charles E. Perkins" wrote:

> Hello Rathi,
>
> By the time the MIB stuff needs to be maintained,
> the mobile node DOES have an IP address.
>
> I think that should make it O.K.
>
> Regards,
> Charlie P.
>
> Ravindra Rathi wrote:
> >
> > Hello all,
> >         At present  tables in RFC-2006 MIB are indexed by ipaddress with
> > the assumption that each mobile node(MN) is uniquely going to be
> > identified by the
> > ipaddress. Now since MN can be identified by network access identifier
> > (NAI) and
> > ipaddress assigned to MN can change across registrations with
> > home-agent,
> > tables in MIB need to support NAI to reflect correct information.
> >
> > Thanks,
> > Rathi

--
Ravindra Rathi
Cisco Systems
"Waterford", #9, Brunton Road
Bangalore-560 001
Tel: +91-80-532 1300 - 1306 x: 6315


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Nov  5 16:47:32 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02600
	for <mobileip-archive@LISTS.IETF.ORG>; Sun, 5 Nov 2000 16:47:31 -0500 (EST)
Received: from standards (47.234.32.16:1823) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB018E@standards.nortelnetworks.com>; 5 Nov 2000 16:29:31 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 76934 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 5 Nov 2000 16:29:30 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB018C@standards.nortelnetworks.com>; 5 Nov 2000 16:29:30 -0500
Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id NAA08196; Sun, 5 Nov 2000 13:45:35
          -0800 (PST)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by
          sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with
          ESMTP id NAA08439; Sun, 5 Nov 2000 13:45:34 -0800 (PST)
Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by
          jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id
          eA5LjY2770438; Sun, 5 Nov 2000 13:45:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: LCx5L75YfrfXGySQMSkHvg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc
Approved-By:  Samita Chakrabarti <Samita.Chakrabarti@ENG.SUN.COM>
Message-ID:  <200011052145.eA5LjY2770438@jurassic.eng.sun.com>
Date:         Sun, 5 Nov 2000 13:46:05 -0800
Reply-To: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>
Subject:      Re: [MOBILE-IP] RFC 2344 Reverse Tunnel Broadcast/Multicast   
              clarification
X-To:         kleung@cisco.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>
> This doesn't seem to cover how FA should deal with reverse tunnel in Direct
> Delivery Style?  What is the explicit behavior of FA when it receives
> broadcast/multicast datagrams from MN in this Delivery mode?  Should FA
> drop these packets since RFC is stating that Encap Delivery Style MUST be
> used by MN?  Or should FA process them itself (which means local, not
> reverse tunneling)?
>
> Note that agent solicitations may be multicasts.
>
> I'm interpreting that FA should process these packets, as in default
> non-reverse tunnel behavior.  But would like to get explicit
> definition.  Thanks.

In our implementation of direct delivery mode, multicast/broadcast packets are
not reverse tunneled and FA performs it's usual processing for multicast
and broadcast packets.


-Samita


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Nov  5 17:43:12 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20479
	for <mobileip-archive@LISTS.IETF.ORG>; Sun, 5 Nov 2000 17:43:11 -0500 (EST)
Received: from standards (47.234.32.16:4220) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB01EA@standards.nortelnetworks.com>; 5 Nov 2000 17:25:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 77056 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 5 Nov 2000 17:25:21 -0500
Received: from mailhost.iprg.nokia.com (205.226.5.12:19650) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB01E8@standards.nortelnetworks.com>; 5 Nov 2000 17:25:21
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA01084;
          Sun, 5 Nov 2000 14:41:26 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA5MfN513634; Sun, 5 Nov 2000 14:41:23
          -0800
X-Virus-Scanned:  Sun, 5 Nov 2000 14:41:23 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from Icharliep-1.iprg.nokia.com (205.226.22.18,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdgzgO49; Sun, 05 Nov 2000
          14:41:19 PST
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <3A02D145.729B2D94@cisco.com> <3A02DA83.C0DDB8C7@iprg.nokia.com>
            <3A05473E.C35B6F65@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Charlie Perkins <charliep@IPRG.NOKIA.COM>
Message-ID:  <3A05E188.185FE9A6@iprg.nokia.com>
Date:         Sun, 5 Nov 2000 14:39:04 -0800
Reply-To: Charlie Perkins <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Charlie Perkins <charliep@IPRG.nokia.com>
Organization: Nokia
Subject:      Re: [MOBILE-IP] RFC-2006 MIB upgrade is required
X-To:         Ravindra Rathi <rathi@cisco.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Rathi,

Perhaps Mobile IP is not the only protocol that has to deal
with identifying nodes that can have dynamically allocated
IP addresses.  Is there a lesson we can learn from other
protocols?

I think it is good to keep in mind that the NAI may not be
sufficient, since a mobile node may eventually use other ways
to identify itself that we don't know about yet.

Regards,
Charlie P.


Ravindra Rathi wrote:

> Hello Charlie,
>         I will explain my point by taking specfic examples of few tables in
> MIB.
>
> 1. haCounterTable
> -------------------
>  Description of table says  "A table containing registration statistics for
> all
>  mobile nodes authorized to use this home agent."
>             If mobile node (MN) dynamically gets ipaddress based on NAI, then
> there can be more that one entry in the table for the same MN since it is
> indexed by home address of MN which can change across registrations.
> Essentially in that case information in this table would not reflect
> statistics for given MN correctly.
>
> 2. mipSecViolationTable
> -------------------------
>             If there is a security violation from one of the MNs which uses
> NAI, then
> there will be entry in this table with index being ipaddress of MN.  There can
> be two problems here.
>     i ) MN might not have got ipaddress yet.
>    ii)   The entry  can't really identify the  MN since the  ipaddress is not
> tied to particular MN.
>
> 3. mipSecAssocTable
> ----------------------
>             Security associations between MNs (which are based on NAI ) and
> home agent or  foreign agent  can't be retrieved through this table.
>
> --Rathi
>
> "Charles E. Perkins" wrote:
>
> > Hello Rathi,
> >
> > By the time the MIB stuff needs to be maintained,
> > the mobile node DOES have an IP address.
> >
> > I think that should make it O.K.
> >
> > Regards,
> > Charlie P.
> >
> > Ravindra Rathi wrote:
> > >
> > > Hello all,
> > >         At present  tables in RFC-2006 MIB are indexed by ipaddress with
> > > the assumption that each mobile node(MN) is uniquely going to be
> > > identified by the
> > > ipaddress. Now since MN can be identified by network access identifier
> > > (NAI) and
> > > ipaddress assigned to MN can change across registrations with
> > > home-agent,
> > > tables in MIB need to support NAI to reflect correct information.
> > >
> > > Thanks,
> > > Rathi
>
> --
> Ravindra Rathi
> Cisco Systems
> "Waterford", #9, Brunton Road
> Bangalore-560 001
> Tel: +91-80-532 1300 - 1306 x: 6315


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov  6 04:44:01 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07907
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Nov 2000 04:44:00 -0500 (EST)
Received: from standards (47.234.32.16:2734) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB050D@standards.nortelnetworks.com>; Mon, 6 Nov 2000 4:24:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 78087 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 04:24:09 -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB050B@standards.nortelnetworks.com>; Mon, 6 Nov 2000 4:24:08
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eA69e3b18762; Mon, 6 Nov 2000 10:40:05 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr
          [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with
          ESMTP id KAA09675; Mon, 6 Nov 2000 10:40:03 +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.9.3/8.9.3) with
          ESMTP id KAA71681; Mon, 6 Nov 2000 10:41:20 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011060941.KAA71681@givry.rennes.enst-bretagne.fr>
Date:         Mon, 6 Nov 2000 10:41:20 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Sun, 05 Nov 2000 14:04:41 +1100. 
              <4B6BC00CD15FD2119E5F0008C7A419A50C613D85@eaubrnt018.epa.ericsson.se>

 In your previous mail you wrote:

        => Which context is RFC 2462 written into ?

=> the same than RFC 2461!

        I'm referring to links that use DAD I don't see a
        need to refer to "a" link type.

=> but "links that use DAD" refer only to one kind of links
(no point-to-point, no NBMA).

        If your link does not use DAD or uses PPP ...etc
        then you do not need to worry about this.
        But if you're running 802.11 for example then
        you probably will use DAD.

=> 802.11 with overlapping cells is one link type where you should use DAD
but in some situation you can['t] use it in time. Mu concern is the DAD issue
exists only for some special links, not in general, then the mobile IPv6
document is not the best place to deal with it. For instance you can't
put a MUST for something specific...

        Stateless autoconfiguration and MIPv6 are independant
        of the underlying layers.

=> neighbor discovery is dependent of the underlying layer in practice then
or you say nothing for special cases in the mobile IPv6 document (the current
case) and you produce an additional "application" document, or you have
to add something for every cases in the mobile IPv6 document. The result
will be the same but perhaps not at the same date...
To summary: the mobile IPv6 document must NOT do the assumption that
cellular == wireless == mobility!

   >    So what I have in mind is very simple,
   >
   >    execute handoff,
   >
   > => how the handoff is detected is very important: in many cases
   > you still use the old COA on the new link just because you don't
   > know it is a new one.
   >
        => That's a separate issue. I'm talking about the case
        when you know that you moved. That's what I meant
        by "execute handoff" above.

=> the term "you know that you moved" is not enough accurate because
the important point is to know that you are moving before to be attached
to the new link. If you can't know then if someone uses the same interface ID
then you'll kill it, if you can know then you can (then must) avoid this
situation, ie. DAD can/must be done before sending any (other) packets on the
link. Of course this really depends on how the movement is detected and done
at the layer 2 (then the details should not be in the mobile IPv6 primary
document).

        The bottom line is you don't know that you moved
        (on L3) unless you get a new RA and you lose your
        reachability to your old default router.

=> this is a special case because you have moved from one link to another
link without a reliable layer 2 indication (like a carrier loss followed
by a restart). This is not the general case. The other case is not too.
gain cellular != wireless != mobility

        When that happens and you get a new COA then you need to
        follow RFC 2462. Hence the delays. There is an interworking
        problem between the 2 standards clearly.

=> there is a rationate for RFC 2462. The idea of DAD is not only
to detect collisions but also to detect them before bad consequences
of collisions. For the first point you can (then should) do a DAD
at any time, for the second (which is important in the real world)
you need to perform a DAD before using the address, ie. before
sending any other packets.
 Then if you apply this to our discussion you get two different cases:
 - you know you have moved too late then you can do the DAD when you'd like,
   of course the sooner is the better but if you collides you've already
   collided.
 - you know you are attaching to a new link then you must perform a DAD,
   for instance if you are adding a new Ethernet interface to your laptop
   you must keep the DAD phase, the only "improvement" you can do is
   to remove 0 to MAX_RTR_SOLICITATION_DELAY of the end of 5.4.2.

To quote RFC 2462:

   It should also be noted that Duplicate Address Detection must be
   performed prior to assigning an address to an interface in order to
   prevent multiple nodes from using the same address simultaneously.
   If a node begins using an address in parallel with Duplicate Address
   Detection, and another node is already using the address, the node
   performing Duplicate Address Detection will erroneously process
   traffic intended for the other node, resulting in such possible
   negative consequences as the resetting of open TCP connections.

   > => a simple(r|st) solution is to use only point-to-point links
   > where IPv6CP (or a similar tool) will do the DAD for free. This is
   > why the context is important!
   >
        => This is one scenario. Clearly we can't enforce that in all cases.

=> no special case can be enforced in all cases... We should agree
about this (ie. "PPP everywhere" is just a counter-provocation :-).

Regards

Francis.Dupont@enst-bretagne.fr

PS: the simplest (and cleanest) way to solve this issue is to write
an IPv6-over-foo document about IEEE 802.11-like networks. The DAD
behavior will be a link property and it won't be applicable to
IEEE 802.3 networks for instance.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov  6 09:14:22 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02227
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Nov 2000 09:14:22 -0500 (EST)
Received: from standards (47.234.32.16:4751) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0656@standards.nortelnetworks.com>; Mon, 6 Nov 2000 8:56:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 78506 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 08:56:03 -0500
Received: from ish7.ericsson.com.au (203.61.155.111:61855) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB0654@standards.nortelnetworks.com>; Mon, 6 Nov 2000 8:56:02
          -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id BAA15253; Tue, 7
          Nov 2000 01:08:55 +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id BAA04714; Tue, 7
          Nov 2000 01:11:35 +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <V42TW8H2>; Tue, 7 Nov 2000 01:11:46 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613D8D@eaubrnt018.epa.ericsson.se>
Date:         Tue, 7 Nov 2000 01:11:39 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
X-To:         Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>       Stateless autoconfiguration and MIPv6 are independant
>       of the underlying layers.
>
> => neighbor discovery is dependent of the underlying layer in practice
> then
> or you say nothing for special cases in the mobile IPv6 document (the
> current
> case) and you produce an additional "application" document, or you have
> to add something for every cases in the mobile IPv6 document. The result
> will be the same but perhaps not at the same date...
>
        => I guess I don't see it as a very special case. There is a close
        relationship between stateless configuration and DAD. Since MIPv6
        implicitly assumes the use of stateless address autoconfiguration
        then I think it is fair to address DAD. If you believe that this is
a special
        case then I can pick many parts of the spec where there are
underlying
        assumptions about certain types of media.

> To summary: the mobile IPv6 document must NOT do the assumption that
> cellular == wireless == mobility!
>
        => I'm not sure where you read that in what I'm saying. BTW this
        issue is irrelevant for cellular and is not specific for wireless
systems.


>       The bottom line is you don't know that you moved
>       (on L3) unless you get a new RA and you lose your
>       reachability to your old default router.
>
> => this is a special case because you have moved from one link to another
> link without a reliable layer 2 indication (like a carrier loss followed
> by a restart). This is not the general case. The other case is not too.
>
        => An RA is an L3 indicaion. MIPv6 addresses L3 mobility
        There is no need for assuming L2 indication in the MN. They would
        help of course but that assumption is definitely not generic
        for all cases.

> gain cellular != wireless != mobility
>
        => I know. I don't see where you read the oppsite of that in
        what I'm saying.

>         When that happens and you get a new COA then you need to
>         follow RFC 2462. Hence the delays. There is an interworking
>       problem between the 2 standards clearly.
>
> => there is a rationate for RFC 2462. The idea of DAD is not only
> to detect collisions but also to detect them before bad consequences
> of collisions. For the first point you can (then should) do a DAD
> at any time, for the second (which is important in the real world)
> you need to perform a DAD before using the address, ie. before
> sending any other packets.
>  Then if you apply this to our discussion you get two different cases:
>  - you know you have moved too late then you can do the DAD when you'd
> like,
>    of course the sooner is the better but if you collides you've already
>    collided.
>
>  - you know you are attaching to a new link then you must perform a DAD,
>    for instance if you are adding a new Ethernet interface to your laptop
>    you must keep the DAD phase, the only "improvement" you can do is
>    to remove 0 to MAX_RTR_SOLICITATION_DELAY of the end of 5.4.2.
>
> To quote RFC 2462:
>
>    It should also be noted that Duplicate Address Detection must be
>    performed prior to assigning an address to an interface in order to
>    prevent multiple nodes from using the same address simultaneously.
>    If a node begins using an address in parallel with Duplicate Address
>    Detection, and another node is already using the address, the node
>    performing Duplicate Address Detection will erroneously process
>    traffic intended for the other node, resulting in such possible
>    negative consequences as the resetting of open TCP connections.
>
        => I agree with the rationale. However my point is there is some
        conflict with "fast mobility".


> PS: the simplest (and cleanest) way to solve this issue is to write
> an IPv6-over-foo document about IEEE 802.11-like networks. The DAD
> behavior will be a link property and it won't be applicable to
> IEEE 802.3 networks for instance.
>
        => That's one way of doing it. But of course it has to be done
        for each case. I don't see a major problem with that as long
        as something is done about it. It is only a problem when
        mobility is considered.

        Regards,
        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov  6 09:34:55 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08959
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Nov 2000 09:34:54 -0500 (EST)
Received: from standards (47.234.32.16:4751) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB06D0@standards.nortelnetworks.com>; Mon, 6 Nov 2000 9:16:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 78661 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 09:16:36 -0500
Received: from ns1.comversens.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB06CE@standards.nortelnetworks.com>; Mon, 6 Nov 2000 9:16:36
          -0500
Received: from mail-bridge.btrd.bostontechnology.com (host.comversens.com
          [63.64.185.2]) by ns1.comversens.com (8.9.1b+Sun/8.9.1) with ESMTP id
          JAA26441 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 6 Nov
          2000 09:33:37 -0500 (EST)
Received: by mail-bridge.btrd.bostontechnology.com with Internet Mail Service
          (5.5.2652.78) id <WGGMDQZ3>; Mon, 6 Nov 2000 09:31:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Safi, Raymond" <RSafi@COMVERSENS.COM>
Message-ID:  <35A7D40B978CD311AF05002048404D34021A0AA3@wm2.btrd.bostontechnology.com>
Date:         Mon, 6 Nov 2000 09:30:03 -0500
Reply-To: "Safi, Raymond" <RSafi@comversens.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Safi, Raymond" <RSafi@comversens.com>
Subject:      [MOBILE-IP] unsubscribe
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Unsubscribe please.

-----Original Message-----
From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
Sent: Friday, November 03, 2000 8:40 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] How Mobile IPv6 should handle home network
renumbering


Hello again,

In Ken's note, a proposal is made for how the home agent
should forward relevant router advertisement information to
the mobile node, when the mobile node is away from its
home network.

I have devised an algorithm by which a home agent can
delay the transmission of this information to the mobile
node, in hopes that the actual transmission can be avoided
entirely if the mobile node might send a Binding Update
to the home agent.  In that case, the home agent could
include all the relevant information in the Binding
Acknowledgement.

Item 2 is "What triggers a home agent to send router"

Ken suggested:

> Item 2 (perhaps replace similar text in section 9.7)
> ====================================================
>
> A home agent serving a mobile node SHOULD construct and
> tunnel to the mobile node a new Router Advertisement when
> any of the following conditions occur:
>
>   o A valid or preferred lifetime of a prefix in the
>     aggregate list of prefixes is suddenly reduced to
>     less than HomeRtrAdvInterval.
>
>   o The state of the flags for a prefix in the aggregate
>     list changes.
>
>   o A new prefix is created in the aggregate list.
>
> The home agent constructs a new Router Advertisement message
> containing no options other than the Prefix Information options
> describing the prefixes for which one of the conditions above
> has occurred since the last Router Advertisement tunneled to and
> acknowledged by the mobile node.
>
> In addition, the home agent MUST send a router advertisement
> with all prefixes in the aggregate list to the mobile node at
> least once per HomeRtrAdvInterval and upon receipt of a valid
> Router Solicitation from the mobile node.
>
> The home agent MAY (SHOULD?) rate limit the frequency at which it
> sends Router Advertisements to the mobile node by delaying transmission
> until receipt of a Binding Update option from the mobile node.
> When multiple conditions occur at or near the same time, the
> home agent SHOULD attempt to combine them into a single Router
> Advertisement message to the mobile node.

Instead of a specific rate-limiting feature, I suggest the following
algorithm:

===== How to send router advertisements to mobile nodes.

- If a mobile node sends a solicitation, answer with everything.

- If a prefix changes state in a way that causes a mobile node's
  address to go deprecated, send an advertisement right away.

- If the mobile node's binding expires before the advertised
  Preferred Lifetime, do not schedule the advertisement.
  The mobile node will get the revised information in its next
  Binding Acknowledgement.

- If a prefix is added, or if it changes in any way that does not
  cause the mobile node's address to go deprecated, ensure that
  a transmission is scheduled at time RAND_ADV_DELAY in the future.

- If a prefix advertisement is scheduled, and a Binding
  Update arrives, perform that advertisement and include
  the information in a Router Advertisement that has the
  Binding Acknowledgement as a Destination Option.  Remove
  the future scheduled advertisement.

===== How to compute RAND_ADV_DELAY, the offset from the
      current time for the scheduled transmission

If there is a transmission already scheduled, then
 if the current RAND_ADV_DELAY would cause another
 transmission BEFORE the Preferred Lifetime of the
 mobile node's home address derived from the prefix
 whose advertisement information has changed, then
               add the new information to be transmitted
               to the existing scheduled transmission
               -- return.
          otherwise,
               continue with the following computation,
               and add the data from the existing scheduled
               transmission to the newly scheduled transmission,
              deleting the previously scheduled transmission
               event.

If the mobile node's binding expires after the Preferred
Lifetime, then compute
           MAX_SCHEDULE_DELAY ==
                     min (MAX_PFX_ADV_DELAY, Preferred Lifetime)
for the newly advertised Preferred Lifetime.
Then compute RAND_ADV_DELAY =
             MinRtrAdvInt + rand()*{MAX_SCHEDULE_DELAY - MinRtrAdvInt}

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

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov  6 10:38:44 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27348
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Nov 2000 10:38:44 -0500 (EST)
Received: from standards (47.234.32.16:4751) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB07A2@standards.nortelnetworks.com>; Mon, 6 Nov 2000 10:20:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 78935 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 10:20:29 -0500
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBB07A0@standards.nortelnetworks.com>; Mon, 6 Nov 2000 10:20:29
          -0500
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP
          id eA6FaZZ06525 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 6
          Nov 2000 16:36:36 +0100 (MET)
Received: from era.ericsson.se by era-t.ericsson.se
          (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA01785; Mon, 6 Nov 2000 16:36:35
          +0100
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
References: <3A036088.DE8D294D@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Mattias Pettersson <mattias.pettersson@ERA.ERICSSON.SE>
Message-ID:  <3A06CFE4.73C2CE99@era.ericsson.se>
Date:         Mon, 6 Nov 2000 16:36:04 +0100
Reply-To: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Radio Systems AB
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home network
              renumbering
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,

Francis wrote in another thread:

> The issue is what happens if the home link is renumbered when the MN is
> stopped. In fact this depends on how the MN knows its home prefix(es):
>  - very stupid implementations believe the MN is started at home then
>    the home prefixes will be prefixes of the first attached link: no
>    problem with renumbering.
>  - stupid implementations use a static config in order to know home
>    prefixes then if the config is too old the MN will not be able to
>    find its home link (and a home agent).
>  - someone suggested in the list to use a name which can be updated
>    when the home prefix is renumbered (but not renamed :-). It is a
>    fine idea out of the scope of the mobile IPv6 draft.
> I think most implementations use the second way (static config)...
>

I've studied the thread above slightly and am a bit curious on the
effects
of the new additions to the I-D below. It's still the bootstrapping
procedure which is of most interest; the renumbering phase is a special
case of the former. So: how does the MN find it's home addresses and
it's
home agents?

1. The MN finds out its home prefix.
2. MN performs DHAAD to find unicast address of an HA.
3. MN sends RS to HA.
4. HA sends RA with prefix list to MN.
5. MN builds Home Addresses for all prefixes, by using address method
stated in prefix info.
6. MN registers each Home Address.
7. HA might help in address configuration (e.g. DAD)
8. DNS should be updated, depending on address configuration method (it
should be done by the MN at this point, not earlier, IMO).

Note that MN doesn't have a Home Address before step 5.

If home network renumbering occurs, while the MN is away from home, HA
normally takes care of informing the MN about new home prefixes. The MN
would run step 4-8 to synchronize with the renumbering.

However, in the case when the MN is turned off for an extended period,
the
MN won't be able to find it's HA again, and not even it's home prefix to
be
able to run DHAAD. This is the same case as initial bootstrapping. Step
1
has to be performed.

As Francis said above, most implementations assume a manual
configuration
of 1, i.e. the home prefix. From there on you can find out the home
agents'
anycast address and find a HA to register with. With Ken's contribution
we
now have a way to find out all home addresses (BTW, what's been done in
the
field of stateful autoconf of Home address and MIPv6?).

What we need at this stage is a new fall-back level, where the MN can
find
it's home prefix independently of IP. So this is where AAA comes in? MN
would only need to know it's name (NAI?). Everything else can be
resolved
from this.

/Mattias

Charlie Perkins wrote:

> Hello everyone,
>
> I'm forwarding to these lists some text supplied by Ken
> Powell for updating relevant sections of the Mobile IPv6
> draft.  I find that Ken's proposed modifications are
> quite reasonable and answer many outstanding open issues.
> In subsequent messages, I will elaborate on some details
> about _when_ a home agent should send new prefix information
> to the mobile node.  However, I thought it would be easiest
> to reproduce Ken's original message in its entirety, so as
> not to disrupt a very coherent presentation.
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov  6 11:55:49 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20422
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Nov 2000 11:55:48 -0500 (EST)
Received: from standards (47.234.32.16:4533) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0856@standards.nortelnetworks.com>; Mon, 6 Nov 2000 11:37:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 79169 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 11:37:46 -0500
Received: from iol.unh.edu (mars.iol.unh.edu) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBB0854@standards.nortelnetworks.com>; Mon, 6 Nov 2000 11:37:45
          -0500
Received: from localhost (jfl@localhost) by iol.unh.edu (8.9.3/8.9.3) with
          ESMTP id LAA03344; Mon, 6 Nov 2000 11:55:56 -0500 (EST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved-By:  "John F. Leser" <jfl@IOL.UNH.EDU>
Message-ID:  <Pine.SGI.4.20.0011061115090.29946-100000@mars.iol.unh.edu>
Date:         Mon, 6 Nov 2000 11:55:56 -0500
Reply-To: "John F. Leser" <jfl@iol.unh.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "John F. Leser" <jfl@iol.unh.edu>
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home network
              renumbering
X-To:         Charlie Perkins <charliep@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <3A0368F3.5C3C4432@iprg.nokia.com>

Hi,

I'd like to make some suggestions to simplify this a bit and to reduce the
overhead of keeping the MN updated with information about the home
network:

My suggestion is that the HA only tunnel router advertisements in the
situations already given in section 9.7.  In addition, the HA includes a
router advertiment in every binding acknowledgement sent in response to a
successful home registration request.  Since the MN's home registration
binding will always have a lifetime that is less than the lifetime of its
home address, this mechanism will keep the MN's home address up-to-date.

In addition, whenever a home registration binding update passes IPSEC,
but fails for some other reason, it includes an RA with the binding ack
(rejection).  The MN will then reconfigure based on this information and
attempt the registration again.  This serves as a replacement for mobile
node's sending router solicitations to the home network.

Tunneled router advertisments are sent as described in 9.7, except that
all prefix information in the aggregate list is included.

Obviously in all cases the router advertisements must be covered by IPSEC.

What is the rationale for clearing the R bit and Router ID infomation
in the prefixes in the aggregate list?  Including this info could keep
this MN's home agent list updated with additional home agents to use if
the current one fails.  If the MN's processing for tunneled advertisements
is properly specified, I don't think there's a risk of this information
being misinterpreted.

There should be wording in the spec along the lines of "the Home Agent
MUST not include the prefix information in the aggregate list in its
router advertisements multicast on-link"


On Fri, 3 Nov 2000, Charlie Perkins wrote:

> Hello again,
>
> In Ken's note, a proposal is made for how the home agent
> should forward relevant router advertisement information to
> the mobile node, when the mobile node is away from its
> home network.
>
> I have devised an algorithm by which a home agent can
> delay the transmission of this information to the mobile
> node, in hopes that the actual transmission can be avoided
> entirely if the mobile node might send a Binding Update
> to the home agent.  In that case, the home agent could
> include all the relevant information in the Binding
> Acknowledgement.
>
> Item 2 is "What triggers a home agent to send router"
>
> Ken suggested:
>
> > Item 2 (perhaps replace similar text in section 9.7)
> > ====================================================
> >
> > A home agent serving a mobile node SHOULD construct and
> > tunnel to the mobile node a new Router Advertisement when
> > any of the following conditions occur:
> >
> >   o A valid or preferred lifetime of a prefix in the
> >     aggregate list of prefixes is suddenly reduced to
> >     less than HomeRtrAdvInterval.
> >
> >   o The state of the flags for a prefix in the aggregate
> >     list changes.
> >
> >   o A new prefix is created in the aggregate list.
> >
> > The home agent constructs a new Router Advertisement message
> > containing no options other than the Prefix Information options
> > describing the prefixes for which one of the conditions above
> > has occurred since the last Router Advertisement tunneled to and
> > acknowledged by the mobile node.
> >
> > In addition, the home agent MUST send a router advertisement
> > with all prefixes in the aggregate list to the mobile node at
> > least once per HomeRtrAdvInterval and upon receipt of a valid
> > Router Solicitation from the mobile node.
> >
> > The home agent MAY (SHOULD?) rate limit the frequency at which it
> > sends Router Advertisements to the mobile node by delaying transmission
> > until receipt of a Binding Update option from the mobile node.
> > When multiple conditions occur at or near the same time, the
> > home agent SHOULD attempt to combine them into a single Router
> > Advertisement message to the mobile node.
>
> Instead of a specific rate-limiting feature, I suggest the following
> algorithm:
>
> ===== How to send router advertisements to mobile nodes.
>
> - If a mobile node sends a solicitation, answer with everything.
>
> - If a prefix changes state in a way that causes a mobile node's
>   address to go deprecated, send an advertisement right away.
>
> - If the mobile node's binding expires before the advertised
>   Preferred Lifetime, do not schedule the advertisement.
>   The mobile node will get the revised information in its next
>   Binding Acknowledgement.
>
> - If a prefix is added, or if it changes in any way that does not
>   cause the mobile node's address to go deprecated, ensure that
>   a transmission is scheduled at time RAND_ADV_DELAY in the future.
>
> - If a prefix advertisement is scheduled, and a Binding
>   Update arrives, perform that advertisement and include
>   the information in a Router Advertisement that has the
>   Binding Acknowledgement as a Destination Option.  Remove
>   the future scheduled advertisement.
>
> ===== How to compute RAND_ADV_DELAY, the offset from the
>       current time for the scheduled transmission
>
> If there is a transmission already scheduled, then
>  if the current RAND_ADV_DELAY would cause another
>  transmission BEFORE the Preferred Lifetime of the
>  mobile node's home address derived from the prefix
>  whose advertisement information has changed, then
>                add the new information to be transmitted
>                to the existing scheduled transmission
>                -- return.
>           otherwise,
>                continue with the following computation,
>                and add the data from the existing scheduled
>                transmission to the newly scheduled transmission,
>               deleting the previously scheduled transmission
>                event.
>
> If the mobile node's binding expires after the Preferred
> Lifetime, then compute
>            MAX_SCHEDULE_DELAY ==
>                      min (MAX_PFX_ADV_DELAY, Preferred Lifetime)
> for the newly advertised Preferred Lifetime.
> Then compute RAND_ADV_DELAY =
>              MinRtrAdvInt + rand()*{MAX_SCHEDULE_DELAY - MinRtrAdvInt}
>
> ===================================================
>
> Regards,
> Charlie P.
>


-------------------------------------------------------------------
John Leser                      UNH InterOperability Lab
IP/Routing Consortium Engineer  Morse Hall, 39 College Rd, Room 332
Tel: (603) 862-0090 (8-5 EST)   Durham, NH 03824-3525
Fax: (603) 862-1761             Web: www.iol.unh.edu
-------------------------------------------------------------------


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov  6 12:13:29 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28329
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Nov 2000 12:13:28 -0500 (EST)
Received: from standards (47.234.32.16:4533) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB08C4@standards.nortelnetworks.com>; Mon, 6 Nov 2000 11:55:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 79310 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 11:55:06 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB08C2@standards.nortelnetworks.com>; Mon, 6 Nov 2000 11:55:05
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA14013;
          Mon, 6 Nov 2000 09:11:13 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA6HBAs00872; Mon, 6 Nov 2000 09:11:10
          -0800
X-Virus-Scanned:  Mon, 6 Nov 2000 09:11:10 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdzcE7l5; Mon, 06 Nov 2000
          09:11:02 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <Pine.SGI.4.20.0011061115090.29946-100000@mars.iol.unh.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A06E629.CE74C223@iprg.nokia.com>
Date:         Mon, 6 Nov 2000 09:11:05 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home network
              renumbering
X-To:         "John F. Leser" <jfl@iol.unh.edu>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello John,

I'm not comfortable with adding so much extra data to every
Binding Acknowledgement, especially when so many times it will
be useless, repetitive data.  That seems very uneconomical.
This wouldn't be an issue over wired links, but over wireless
links it seems unwise to me.  If you look at the situation at
the receiving end, where a single access router may be relaying
information to many mobile nodes from many home networks, you
can see that adding unnecessary baggage into Binding Acknowlegements
could cause unwelcome contention over the wide area airlink.

The rationale behind trying to spread out the router advertisements
after the local advertisements indicate a change, is to avoid
the situation where a home agent sends out 10,000 change notices
all at once.  I reckon we should design the protocol so that it
is operationally reasonable to allow a home agent to serve very
many mobile nodes.

I'll have to study the issue with the 'R' bit some more
(a "bit more", you might say) before further comment.

Regards,
Charlie P.



"John F. Leser" wrote:
>
> Hi,
>
> I'd like to make some suggestions to simplify this a bit and to reduce the
> overhead of keeping the MN updated with information about the home
> network:
>
> My suggestion is that the HA only tunnel router advertisements in the
> situations already given in section 9.7.  In addition, the HA includes a
> router advertiment in every binding acknowledgement sent in response to a
> successful home registration request.  Since the MN's home registration
> binding will always have a lifetime that is less than the lifetime of its
> home address, this mechanism will keep the MN's home address up-to-date.
>
> In addition, whenever a home registration binding update passes IPSEC,
> but fails for some other reason, it includes an RA with the binding ack
> (rejection).  The MN will then reconfigure based on this information and
> attempt the registration again.  This serves as a replacement for mobile
> node's sending router solicitations to the home network.
>
> Tunneled router advertisments are sent as described in 9.7, except that
> all prefix information in the aggregate list is included.
>
> Obviously in all cases the router advertisements must be covered by IPSEC.
>
> What is the rationale for clearing the R bit and Router ID infomation
> in the prefixes in the aggregate list?  Including this info could keep
> this MN's home agent list updated with additional home agents to use if
> the current one fails.  If the MN's processing for tunneled advertisements
> is properly specified, I don't think there's a risk of this information
> being misinterpreted.
>
> There should be wording in the spec along the lines of "the Home Agent
> MUST not include the prefix information in the aggregate list in its
> router advertisements multicast on-link"
>
> On Fri, 3 Nov 2000, Charlie Perkins wrote:
>
> > Hello again,
> >
> > In Ken's note, a proposal is made for how the home agent
> > should forward relevant router advertisement information to
> > the mobile node, when the mobile node is away from its
> > home network.
> >
> > I have devised an algorithm by which a home agent can
> > delay the transmission of this information to the mobile
> > node, in hopes that the actual transmission can be avoided
> > entirely if the mobile node might send a Binding Update
> > to the home agent.  In that case, the home agent could
> > include all the relevant information in the Binding
> > Acknowledgement.
> >
> > Item 2 is "What triggers a home agent to send router"
> >
> > Ken suggested:
> >
> > > Item 2 (perhaps replace similar text in section 9.7)
> > > ====================================================
> > >
> > > A home agent serving a mobile node SHOULD construct and
> > > tunnel to the mobile node a new Router Advertisement when
> > > any of the following conditions occur:
> > >
> > >   o A valid or preferred lifetime of a prefix in the
> > >     aggregate list of prefixes is suddenly reduced to
> > >     less than HomeRtrAdvInterval.
> > >
> > >   o The state of the flags for a prefix in the aggregate
> > >     list changes.
> > >
> > >   o A new prefix is created in the aggregate list.
> > >
> > > The home agent constructs a new Router Advertisement message
> > > containing no options other than the Prefix Information options
> > > describing the prefixes for which one of the conditions above
> > > has occurred since the last Router Advertisement tunneled to and
> > > acknowledged by the mobile node.
> > >
> > > In addition, the home agent MUST send a router advertisement
> > > with all prefixes in the aggregate list to the mobile node at
> > > least once per HomeRtrAdvInterval and upon receipt of a valid
> > > Router Solicitation from the mobile node.
> > >
> > > The home agent MAY (SHOULD?) rate limit the frequency at which it
> > > sends Router Advertisements to the mobile node by delaying transmission
> > > until receipt of a Binding Update option from the mobile node.
> > > When multiple conditions occur at or near the same time, the
> > > home agent SHOULD attempt to combine them into a single Router
> > > Advertisement message to the mobile node.
> >
> > Instead of a specific rate-limiting feature, I suggest the following
> > algorithm:
> >
> > ===== How to send router advertisements to mobile nodes.
> >
> > - If a mobile node sends a solicitation, answer with everything.
> >
> > - If a prefix changes state in a way that causes a mobile node's
> >   address to go deprecated, send an advertisement right away.
> >
> > - If the mobile node's binding expires before the advertised
> >   Preferred Lifetime, do not schedule the advertisement.
> >   The mobile node will get the revised information in its next
> >   Binding Acknowledgement.
> >
> > - If a prefix is added, or if it changes in any way that does not
> >   cause the mobile node's address to go deprecated, ensure that
> >   a transmission is scheduled at time RAND_ADV_DELAY in the future.
> >
> > - If a prefix advertisement is scheduled, and a Binding
> >   Update arrives, perform that advertisement and include
> >   the information in a Router Advertisement that has the
> >   Binding Acknowledgement as a Destination Option.  Remove
> >   the future scheduled advertisement.
> >
> > ===== How to compute RAND_ADV_DELAY, the offset from the
> >       current time for the scheduled transmission
> >
> > If there is a transmission already scheduled, then
> >  if the current RAND_ADV_DELAY would cause another
> >  transmission BEFORE the Preferred Lifetime of the
> >  mobile node's home address derived from the prefix
> >  whose advertisement information has changed, then
> >                add the new information to be transmitted
> >                to the existing scheduled transmission
> >                -- return.
> >           otherwise,
> >                continue with the following computation,
> >                and add the data from the existing scheduled
> >                transmission to the newly scheduled transmission,
> >               deleting the previously scheduled transmission
> >                event.
> >
> > If the mobile node's binding expires after the Preferred
> > Lifetime, then compute
> >            MAX_SCHEDULE_DELAY ==
> >                      min (MAX_PFX_ADV_DELAY, Preferred Lifetime)
> > for the newly advertised Preferred Lifetime.
> > Then compute RAND_ADV_DELAY =
> >              MinRtrAdvInt + rand()*{MAX_SCHEDULE_DELAY - MinRtrAdvInt}
> >
> > ===================================================
> >
> > Regards,
> > Charlie P.
> >
>
> -------------------------------------------------------------------
> John Leser                      UNH InterOperability Lab
> IP/Routing Consortium Engineer  Morse Hall, 39 College Rd, Room 332
> Tel: (603) 862-0090 (8-5 EST)   Durham, NH 03824-3525
> Fax: (603) 862-1761             Web: www.iol.unh.edu
> -------------------------------------------------------------------


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov  6 12:13:29 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28346
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Nov 2000 12:13:29 -0500 (EST)
Received: from standards (47.234.32.16:4533) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB08D3@standards.nortelnetworks.com>; Mon, 6 Nov 2000 11:56:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 79328 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 11:56:21 -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBB08D0@standards.nortelnetworks.com>;
          Mon, 6 Nov 2000 11:56:21 -0500
Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id KAA27228 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 6 Nov 2000 10:12:28
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          JAA05104 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 6 Nov
          2000 09:12:27 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id JAA17916 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 6 Nov 2000 09:12:25
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Patrice Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.973530588.2058.pcalhoun@nasnfs>
Date:         Mon, 6 Nov 2000 09:09:48 -0800
Reply-To: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      [MOBILE-IP] Connectathon 2001 Information
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

FYI.

PatC
----

Plans for Connectathon 2001 are already under way!  The 15th annual
Connectathon event, an interoperability testing event for engineers
only, will be held March 1-8, 2001 in San Jose, California.
Connectathon, sponsored by Sun Microsystems, Inc., hosts nearly 50
companies annually in an effort to test and debug source code which
utilize the following technologies and protocols:

    NFS versions 2, 3 and 4
    NFS over TCP
    WebNFS
    Lock Manager
    NIS/NIS+
    Kerberos
    Automounter
    IPv6
    IPsec
    NDMP
    DHCPv6
    CIFS
    Mobile IPv4
    Mobile IPv6
    Diameter
    Gigabit Ethernet

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

    SCTP

If you are interested in testing SCTP, 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, 2001.  An Early Bird
Discount on booth fees is available to those who register and pay by
December 31, 2000.  For registration information, please see our web
site at http://www.connectathon.org.  Registration is accepted on a
first come basis.  We encourage you to register early but fees are
non-refundable.  Connectathon 2000 was sold out.

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 15th annual Connectathon event!

Audrey Van Belleghem
Connectathon Manager


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov  6 12:28:01 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03623
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Nov 2000 12:27:58 -0500 (EST)
Received: from standards (47.234.32.16:4533) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB097B@standards.nortelnetworks.com>; Mon, 6 Nov 2000 12:09:34 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 79553 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 12:09:33 -0500
Received: from iol.unh.edu (mars.iol.unh.edu) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBB0979@standards.nortelnetworks.com>; Mon, 6 Nov 2000 12:09:33
          -0500
Received: from localhost (jfl@localhost) by iol.unh.edu (8.9.3/8.9.3) with
          ESMTP id MAA03990; Mon, 6 Nov 2000 12:27:49 -0500 (EST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved-By:  "John F. Leser" <jfl@IOL.UNH.EDU>
Message-ID:  <Pine.SGI.4.20.0011061204520.29946-100000@mars.iol.unh.edu>
Date:         Mon, 6 Nov 2000 12:27:49 -0500
Reply-To: "John F. Leser" <jfl@iol.unh.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "John F. Leser" <jfl@iol.unh.edu>
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home network
              renumbering
X-To:         Mattias Pettersson <mattias.pettersson@era.ericsson.se>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <3A06CFE4.73C2CE99@era.ericsson.se>

Mattias,

I'd say you have a valid point - if the MN is off, and renumbering takes
place, this cannot be recovered.  Maybe there should be an
additional bullet in 10.15 of the Mobility Spec,

- If a name service such as DNS is in use, The Mobile Node MAY perform a
reverse lookup on the global address of the Home Agent in order to cache
name information in the Home Agent List.  This MUST only be done once when
the home agents address is first added to the Home Agent List.

in 10.7

- If dynamic home agent discovery fails and the mobile node has cached the
name of one or more home agents it its Home Agent List, the mobile node
MAY attempt to resolve these names through whatever name services are
supported.  If the address returned by the name service is different from
the address stored in the Home Agent List, the mobile node MAY attempt to
register with the home agent at the new address.


-------------------------------------------------------------------
John Leser                      UNH InterOperability Lab
IP/Routing Consortium Engineer  Morse Hall, 39 College Rd, Room 332
Tel: (603) 862-0090 (8-5 EST)   Durham, NH 03824-3525
Fax: (603) 862-1761             Web: www.iol.unh.edu
-------------------------------------------------------------------


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov  6 12:36:08 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05837
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Nov 2000 12:36:07 -0500 (EST)
Received: from standards (47.234.32.16:4533) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB09C8@standards.nortelnetworks.com>; Mon, 6 Nov 2000 12:17:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 79653 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 12:17:44 -0500
Received: from iol.unh.edu (mars.iol.unh.edu) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBB09C6@standards.nortelnetworks.com>; Mon, 6 Nov 2000 12:17:41
          -0500
Received: from localhost (jfl@localhost) by iol.unh.edu (8.9.3/8.9.3) with
          ESMTP id MAA04112; Mon, 6 Nov 2000 12:35:58 -0500 (EST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved-By:  "John F. Leser" <jfl@IOL.UNH.EDU>
Message-ID:  <Pine.SGI.4.20.0011061229420.29946-100000@mars.iol.unh.edu>
Date:         Mon, 6 Nov 2000 12:35:58 -0500
Reply-To: "John F. Leser" <jfl@iol.unh.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "John F. Leser" <jfl@iol.unh.edu>
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home network
              renumbering
X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <3A06E629.CE74C223@iprg.nokia.com>

Charlie,

Maybe have the RA send the prefix info the first time the MN registers
its COA, but thereafter just set a bit in the binding ack that means
"you're prefix information is unchanged."  The bit would cause the MN
to reset all of its prefix timers to what it saw in the last tunneled RA.

Thus the overhead is only high for the first move, which isn't so bad
since its very like onto a network only 1 hop away.

On Mon, 6 Nov 2000, Charles E. Perkins wrote:

>
> Hello John,
>
> I'm not comfortable with adding so much extra data to every
> Binding Acknowledgement, especially when so many times it will
> be useless, repetitive data.  That seems very uneconomical.
> This wouldn't be an issue over wired links, but over wireless
> links it seems unwise to me.  If you look at the situation at
> the receiving end, where a single access router may be relaying
> information to many mobile nodes from many home networks, you
> can see that adding unnecessary baggage into Binding Acknowlegements
> could cause unwelcome contention over the wide area airlink.
>
> The rationale behind trying to spread out the router advertisements
> after the local advertisements indicate a change, is to avoid
> the situation where a home agent sends out 10,000 change notices
> all at once.  I reckon we should design the protocol so that it
> is operationally reasonable to allow a home agent to serve very
> many mobile nodes.
>
> I'll have to study the issue with the 'R' bit some more
> (a "bit more", you might say) before further comment.
>
> Regards,
> Charlie P.
>
>
>
> "John F. Leser" wrote:
> >
> > Hi,
> >
> > I'd like to make some suggestions to simplify this a bit and to reduce the
> > overhead of keeping the MN updated with information about the home
> > network:
> >
> > My suggestion is that the HA only tunnel router advertisements in the
> > situations already given in section 9.7.  In addition, the HA includes a
> > router advertiment in every binding acknowledgement sent in response to a
> > successful home registration request.  Since the MN's home registration
> > binding will always have a lifetime that is less than the lifetime of its
> > home address, this mechanism will keep the MN's home address up-to-date.
> >
> > In addition, whenever a home registration binding update passes IPSEC,
> > but fails for some other reason, it includes an RA with the binding ack
> > (rejection).  The MN will then reconfigure based on this information and
> > attempt the registration again.  This serves as a replacement for mobile
> > node's sending router solicitations to the home network.
> >
> > Tunneled router advertisments are sent as described in 9.7, except that
> > all prefix information in the aggregate list is included.
> >
> > Obviously in all cases the router advertisements must be covered by IPSEC.
> >
> > What is the rationale for clearing the R bit and Router ID infomation
> > in the prefixes in the aggregate list?  Including this info could keep
> > this MN's home agent list updated with additional home agents to use if
> > the current one fails.  If the MN's processing for tunneled advertisements
> > is properly specified, I don't think there's a risk of this information
> > being misinterpreted.
> >
> > There should be wording in the spec along the lines of "the Home Agent
> > MUST not include the prefix information in the aggregate list in its
> > router advertisements multicast on-link"
> >
> > On Fri, 3 Nov 2000, Charlie Perkins wrote:
> >
> > > Hello again,
> > >
> > > In Ken's note, a proposal is made for how the home agent
> > > should forward relevant router advertisement information to
> > > the mobile node, when the mobile node is away from its
> > > home network.
> > >
> > > I have devised an algorithm by which a home agent can
> > > delay the transmission of this information to the mobile
> > > node, in hopes that the actual transmission can be avoided
> > > entirely if the mobile node might send a Binding Update
> > > to the home agent.  In that case, the home agent could
> > > include all the relevant information in the Binding
> > > Acknowledgement.
> > >
> > > Item 2 is "What triggers a home agent to send router"
> > >
> > > Ken suggested:
> > >
> > > > Item 2 (perhaps replace similar text in section 9.7)
> > > > ====================================================
> > > >
> > > > A home agent serving a mobile node SHOULD construct and
> > > > tunnel to the mobile node a new Router Advertisement when
> > > > any of the following conditions occur:
> > > >
> > > >   o A valid or preferred lifetime of a prefix in the
> > > >     aggregate list of prefixes is suddenly reduced to
> > > >     less than HomeRtrAdvInterval.
> > > >
> > > >   o The state of the flags for a prefix in the aggregate
> > > >     list changes.
> > > >
> > > >   o A new prefix is created in the aggregate list.
> > > >
> > > > The home agent constructs a new Router Advertisement message
> > > > containing no options other than the Prefix Information options
> > > > describing the prefixes for which one of the conditions above
> > > > has occurred since the last Router Advertisement tunneled to and
> > > > acknowledged by the mobile node.
> > > >
> > > > In addition, the home agent MUST send a router advertisement
> > > > with all prefixes in the aggregate list to the mobile node at
> > > > least once per HomeRtrAdvInterval and upon receipt of a valid
> > > > Router Solicitation from the mobile node.
> > > >
> > > > The home agent MAY (SHOULD?) rate limit the frequency at which it
> > > > sends Router Advertisements to the mobile node by delaying transmission
> > > > until receipt of a Binding Update option from the mobile node.
> > > > When multiple conditions occur at or near the same time, the
> > > > home agent SHOULD attempt to combine them into a single Router
> > > > Advertisement message to the mobile node.
> > >
> > > Instead of a specific rate-limiting feature, I suggest the following
> > > algorithm:
> > >
> > > ===== How to send router advertisements to mobile nodes.
> > >
> > > - If a mobile node sends a solicitation, answer with everything.
> > >
> > > - If a prefix changes state in a way that causes a mobile node's
> > >   address to go deprecated, send an advertisement right away.
> > >
> > > - If the mobile node's binding expires before the advertised
> > >   Preferred Lifetime, do not schedule the advertisement.
> > >   The mobile node will get the revised information in its next
> > >   Binding Acknowledgement.
> > >
> > > - If a prefix is added, or if it changes in any way that does not
> > >   cause the mobile node's address to go deprecated, ensure that
> > >   a transmission is scheduled at time RAND_ADV_DELAY in the future.
> > >
> > > - If a prefix advertisement is scheduled, and a Binding
> > >   Update arrives, perform that advertisement and include
> > >   the information in a Router Advertisement that has the
> > >   Binding Acknowledgement as a Destination Option.  Remove
> > >   the future scheduled advertisement.
> > >
> > > ===== How to compute RAND_ADV_DELAY, the offset from the
> > >       current time for the scheduled transmission
> > >
> > > If there is a transmission already scheduled, then
> > >  if the current RAND_ADV_DELAY would cause another
> > >  transmission BEFORE the Preferred Lifetime of the
> > >  mobile node's home address derived from the prefix
> > >  whose advertisement information has changed, then
> > >                add the new information to be transmitted
> > >                to the existing scheduled transmission
> > >                -- return.
> > >           otherwise,
> > >                continue with the following computation,
> > >                and add the data from the existing scheduled
> > >                transmission to the newly scheduled transmission,
> > >               deleting the previously scheduled transmission
> > >                event.
> > >
> > > If the mobile node's binding expires after the Preferred
> > > Lifetime, then compute
> > >            MAX_SCHEDULE_DELAY ==
> > >                      min (MAX_PFX_ADV_DELAY, Preferred Lifetime)
> > > for the newly advertised Preferred Lifetime.
> > > Then compute RAND_ADV_DELAY =
> > >              MinRtrAdvInt + rand()*{MAX_SCHEDULE_DELAY - MinRtrAdvInt}
> > >
> > > ===================================================
> > >
> > > Regards,
> > > Charlie P.
> > >
> >
> > -------------------------------------------------------------------
> > John Leser                      UNH InterOperability Lab
> > IP/Routing Consortium Engineer  Morse Hall, 39 College Rd, Room 332
> > Tel: (603) 862-0090 (8-5 EST)   Durham, NH 03824-3525
> > Fax: (603) 862-1761             Web: www.iol.unh.edu
> > -------------------------------------------------------------------
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov  6 12:36:10 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05861
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Nov 2000 12:36:10 -0500 (EST)
Received: from standards (47.234.32.16:4533) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB09CD@standards.nortelnetworks.com>; Mon, 6 Nov 2000 12:18:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 79657 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 12:18:01 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB09CA@standards.nortelnetworks.com>; Mon, 6 Nov 2000 12:18:01
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA16228;
          Mon, 6 Nov 2000 09:33:59 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA6HXvL07950; Mon, 6 Nov 2000 09:33:57
          -0800
X-Virus-Scanned:  Mon, 6 Nov 2000 09:33:57 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdA1lqCM; Mon, 06 Nov 2000
          09:33:49 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <3A036088.DE8D294D@iprg.nokia.com>
            <3A06CFE4.73C2CE99@era.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A06EB7E.2F0768F6@iprg.nokia.com>
Date:         Mon, 6 Nov 2000 09:33:50 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home
              networkrenumbering
X-To:         Mattias Pettersson <mattias.pettersson@era.ericsson.se>
X-cc:         Francis Dupont <Francis.Dupont@inria.fr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Mattias and Francis,


Francis wrote in another thread:

> The issue is what happens if the home link is renumbered when the MN is
> stopped. In fact this depends on how the MN knows its home prefix(es):
>  - very stupid implementations believe the MN is started at home then
>    the home prefixes will be prefixes of the first attached link: no
>    problem with renumbering.
>  - stupid implementations use a static config in order to know home
>    prefixes then if the config is too old the MN will not be able to
>    find its home link (and a home agent).
>  - someone suggested in the list to use a name which can be updated
>    when the home prefix is renumbered (but not renamed :-). It is a
>    fine idea out of the scope of the mobile IPv6 draft.
> I think most implementations use the second way (static config)...

One is left to wonder if there are any intelligent alternatives!

I propose that the protocols and algorithms and procedures for getting
an initial IPv6 home address allocated to a mobile node should all
be declared out of scope, or otherwise we'll never get finished with
the spec.


>Mattias Pettersson wrote:

> I've studied the thread above slightly and am a bit curious on
> the effects of the new additions to the I-D below. It's still
> the bootstrapping procedure which is of most interest; the
> renumbering phase is a special case of the former. So: how does
> the MN find it's home addresses and it's home agents?

Likewise, I sincerely hope that these questions can be declared
out of scope for the current draft.  On the other hand, I think it's
a great discussion.

> 1. The MN finds out its home prefix.
> 2. MN performs DHAAD to find unicast address of an HA.

That's a mighty big rabbit you just pulled out of that there hat ...

> 3. MN sends RS to HA.
> 4. HA sends RA with prefix list to MN.
> 5. MN builds Home Addresses for all prefixes, by using address method
> stated in prefix info.
> 6. MN registers each Home Address.
> 7. HA might help in address configuration (e.g. DAD)
> 8. DNS should be updated, depending on address configuration method (it
> should be done by the MN at this point, not earlier, IMO).

What is the mobile node uses DHCP to update DNS?

> Note that MN doesn't have a Home Address before step 5.

Presumably, that would mean that the protocol you design would
use a link-local address up until that point.

> If home network renumbering occurs, while the MN is away from home, HA
> normally takes care of informing the MN about new home prefixes. The MN
> would run step 4-8 to synchronize with the renumbering.

I'm not disagreeing with you, but my objective is to get the draft
done, and making such dependencies for resynchronization purposes
would be detrimental to that objective.

> However, in the case when the MN is turned off for an extended period,
> the MN won't be able to find it's HA again, and not even it's home prefix
> to be able to run DHAAD. This is the same case as initial bootstrapping.
> Step 1 has to be performed.
>
> As Francis said above, most implementations assume a manual
> configuration of 1, i.e. the home prefix.  From there on you
> can find out the home agents' anycast address and find a HA
> to register with.  With Ken's contribution we now have a way
> to find out all home addresses (BTW, what's been done in the
> field of stateful autoconf of Home address and MIPv6?).

I don't think a mobile node which is currently off-link can bootstrap
from zero.  It has to at least have a security association with the
home agent, and that has to depend on an IPv6 address, so you need to
have an IPv6 address.  We can all try to design a better bootstrapping
mechanism, which would clearly depend on finding new ways to identify
a mobile node (other than using its home address).

It took a year to standardize the Mobile IPv4 NAI extension, and there
are still questions coming up on it.  My goal is to get a new Mobile IPv6
Internet Draft done this week.  I hope we don't have to go down the
path of specifying off-link bootstrapping from zero.


> What we need at this stage is a new fall-back level, where the MN can
> find it's home prefix independently of IP. So this is where AAA comes
> in? MN would only need to know it's name (NAI?). Everything else can be
> resolved from this.

Agreed -- but next year, not this one.


Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov  6 13:14:22 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15313
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Nov 2000 13:14:22 -0500 (EST)
Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0A87@standards.nortelnetworks.com>; Mon, 6 Nov 2000 12:56:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 79900 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 12:56:22 -0500
Received: from iol.unh.edu (mars.iol.unh.edu) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBB0A85@standards.nortelnetworks.com>; Mon, 6 Nov 2000 12:56:22
          -0500
Received: from localhost (jfl@localhost) by iol.unh.edu (8.9.3/8.9.3) with
          ESMTP id NAA04712; Mon, 6 Nov 2000 13:14:36 -0500 (EST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved-By:  "John F. Leser" <jfl@IOL.UNH.EDU>
Message-ID:  <Pine.SGI.4.20.0011061258480.29946-100000@mars.iol.unh.edu>
Date:         Mon, 6 Nov 2000 13:14:35 -0500
Reply-To: "John F. Leser" <jfl@iol.unh.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "John F. Leser" <jfl@iol.unh.edu>
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home
              networkrenumbering
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <3A06EB7E.2F0768F6@iprg.nokia.com>

Comments below.

> One is left to wonder if there are any intelligent alternatives!
>
> I propose that the protocols and algorithms and procedures for getting
> an initial IPv6 home address allocated to a mobile node should all
> be declared out of scope, or otherwise we'll never get finished with
> the spec.
>
I'd rather not see this completely unspecified.  I suggest the core
Mobility spec allow:

1.) Manual config.

2.) With stateless config, a 'button' that says "you are now home"  at
which point the NM takes the current link's stateless info to initialize
or replace its home address(es).

3.) Mention that other statefull mechanisms will likely define their own
way.

>
> >Mattias Pettersson wrote:
>
> > I've studied the thread above slightly and am a bit curious on
> > the effects of the new additions to the I-D below. It's still
> > the bootstrapping procedure which is of most interest; the
> > renumbering phase is a special case of the former. So: how does
> > the MN find it's home addresses and it's home agents?
>
> Likewise, I sincerely hope that these questions can be declared
> out of scope for the current draft.  On the other hand, I think it's
> a great discussion.

I say either include a minor hack based on DNS as a MAY, or leave it
completely out of scope.  This is too rare a case to hold up the draft.
>
> > 1. The MN finds out its home prefix.
> > 2. MN performs DHAAD to find unicast address of an HA.
>
> That's a mighty big rabbit you just pulled out of that there hat ...
>
> > 3. MN sends RS to HA.
> > 4. HA sends RA with prefix list to MN.
> > 5. MN builds Home Addresses for all prefixes, by using address method
> > stated in prefix info.
> > 6. MN registers each Home Address.
> > 7. HA might help in address configuration (e.g. DAD)
> > 8. DNS should be updated, depending on address configuration method (it
> > should be done by the MN at this point, not earlier, IMO).
>
> What is the mobile node uses DHCP to update DNS?

Leave all DHCP issues to be resolved by DHCPv6 or a mobility extension to
DHCPv6.  Likewise with dynamic DNS updates.

If we adopt some incarnation of Ken's idea to keep the MN aware of all
stateless information on the home link, we should define the data
structure on the MN that holds this information so that statefull
protocols can update it.


-------------------------------------------------------------------
John Leser                      UNH InterOperability Lab
IP/Routing Consortium Engineer  Morse Hall, 39 College Rd, Room 332
Tel: (603) 862-0090 (8-5 EST)   Durham, NH 03824-3525
Fax: (603) 862-1761             Web: www.iol.unh.edu
-------------------------------------------------------------------


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov  6 13:32:25 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19435
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Nov 2000 13:32:24 -0500 (EST)
Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0AEC@standards.nortelnetworks.com>; Mon, 6 Nov 2000 13:14:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 80033 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 13:14:08 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB0AEA@standards.nortelnetworks.com>; Mon, 6 Nov 2000 13:14:08
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA21543;
          Mon, 6 Nov 2000 10:30:16 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA6IUFW23136; Mon, 6 Nov 2000 10:30:15
          -0800
X-Virus-Scanned:  Mon, 6 Nov 2000 10:30:15 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from vijayd.iprg.nokia.com (205.226.2.94,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdl8alGH; Mon, 06 Nov 2000
          10:30:10 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <200011041619.RAA65573@givry.rennes.enst-bretagne.fr>
Content-Type: multipart/mixed; boundary="------------B927FD472521FEF3414C6A73"
Approved-By:  vijayd@IPRG.NOKIA.COM
Message-ID:  <3A06F8B2.62617120@iprg.nokia.com>
Date:         Mon, 6 Nov 2000 10:30:11 -0800
Reply-To: Vijay Devarapalli <vijayd@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Vijay Devarapalli <vijayd@IPRG.nokia.com>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of
              "MobilitySupport
              inIPv6"draft]
X-To:         Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------B927FD472521FEF3414C6A73
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Francis Dupont wrote:

> PS 1: the quoted packet's source address is the inner one because at
> the head of the enumeration there is: "Note that the selector checks
> are made on the inner headers not the outer (tunnel) headers."

Inner header if the packet is tunneled. Not otherwise.

Vijay

--------------B927FD472521FEF3414C6A73
Content-Type: text/x-vcard; charset=us-ascii;
 name="vijayd.vcf"
Content-Description: Card for Vijay Devarapalli
Content-Disposition: attachment;
 filename="vijayd.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Devarapalli;Vijay
tel;cell:(650) 302 8629
tel;work:(650) 625 2320
x-mozilla-html:FALSE
org:Nokia Research Center
version:2.1
email;internet:vijayd@iprg.nokia.com
title:Research Enginner
adr;quoted-printable:;;313 Fairchild Drive=0D=0A;Mountain View;CA;95051;USA
x-mozilla-cpt:;-12992
fn:Vijay Devarapalli
end:vcard

--------------B927FD472521FEF3414C6A73--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov  6 13:52:01 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23858
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Nov 2000 13:52:00 -0500 (EST)
Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0B46@standards.nortelnetworks.com>; Mon, 6 Nov 2000 13:33:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 80150 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 13:33:49 -0500
Received: from zcamail05.zca.compaq.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB0B44@standards.nortelnetworks.com>; Mon, 6 Nov 2000 13:33:47
          -0500
Received: by zcamail05.zca.compaq.com (Postfix,
          from userid 12345) id 3CA7E640; Mon,  6 Nov 2000 10:50:36 -0800 (PST)
Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net
          [16.103.129.53]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id
          0C04C7EF; Mon,  6 Nov 2000 10:50:35 -0800 (PST)
Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service
          (5.5.2650.21) id <W1TZPQJW>; Mon, 6 Nov 2000 13:49:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Powell, Ken" <Ken.Powell@COMPAQ.COM>
Message-ID:  <C99A689B0CB9D111AF3F0000F8062CCD08FB83B6@zkoexc2.zko.dec.com>
Date:         Mon, 6 Nov 2000 13:49:46 -0500
Reply-To: "Powell, Ken" <Ken.Powell@compaq.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Powell, Ken" <Ken.Powell@compaq.com>
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home network renumb
              ering
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>,
              "John F. Leser" <jfl@iol.unh.edu>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi John,

I had originally intended to copy the R bit and full IP address
as you suggested. When I reread the definition of the R bit in
section 6.2 again, I noticed:

  "When set, indicates that the prefix field, in addition
   to advertising the indicated prefix, contains a
   complete IP address of the sending router."
                              ==============

Copying the R bit and its associated IP address from another
router would violate this definition. In addition, section 10.17
indicated that a mobile node does the following with this field:

    -  If the Home Agents List entry for the link-local address of
       the home agent sending this Advertisement was not deleted as
       described above, determine any global address(es) of the home
       agent based on each Prefix Information option received in
       this Advertisement in which the Router Address (R) bit is set
       (Section 6.2).  For each such global address determined from
       this Advertisement, add this global address to the list of
       global addresses for this home agent in this Home Agents List
       entry.                ===============

Once again, this would be broken if we passed the R bit and the
IP address of another router.

I suppose special processing for a tunneled router advertisement
could be defined, but I don't see any way for a mobile node to tell
which of multiple possible routers on the home network a particular
address belongs to.

Ken


-----Original Message-----
From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
Sent: Monday, November 06, 2000 12:11 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] How Mobile IPv6 should handle home network
renumbering


Hello John,

I'm not comfortable with adding so much extra data to every
Binding Acknowledgement, especially when so many times it will
be useless, repetitive data.  That seems very uneconomical.
This wouldn't be an issue over wired links, but over wireless
links it seems unwise to me.  If you look at the situation at
the receiving end, where a single access router may be relaying
information to many mobile nodes from many home networks, you
can see that adding unnecessary baggage into Binding Acknowlegements
could cause unwelcome contention over the wide area airlink.

The rationale behind trying to spread out the router advertisements
after the local advertisements indicate a change, is to avoid
the situation where a home agent sends out 10,000 change notices
all at once.  I reckon we should design the protocol so that it
is operationally reasonable to allow a home agent to serve very
many mobile nodes.

I'll have to study the issue with the 'R' bit some more
(a "bit more", you might say) before further comment.

Regards,
Charlie P.



"John F. Leser" wrote:
>
> Hi,
>
> I'd like to make some suggestions to simplify this a bit and to reduce the
> overhead of keeping the MN updated with information about the home
> network:
>
> My suggestion is that the HA only tunnel router advertisements in the
> situations already given in section 9.7.  In addition, the HA includes a
> router advertiment in every binding acknowledgement sent in response to a
> successful home registration request.  Since the MN's home registration
> binding will always have a lifetime that is less than the lifetime of its
> home address, this mechanism will keep the MN's home address up-to-date.
>
> In addition, whenever a home registration binding update passes IPSEC,
> but fails for some other reason, it includes an RA with the binding ack
> (rejection).  The MN will then reconfigure based on this information and
> attempt the registration again.  This serves as a replacement for mobile
> node's sending router solicitations to the home network.
>
> Tunneled router advertisments are sent as described in 9.7, except that
> all prefix information in the aggregate list is included.
>
> Obviously in all cases the router advertisements must be covered by IPSEC.
>
> What is the rationale for clearing the R bit and Router ID infomation
> in the prefixes in the aggregate list?  Including this info could keep
> this MN's home agent list updated with additional home agents to use if
> the current one fails.  If the MN's processing for tunneled advertisements
> is properly specified, I don't think there's a risk of this information
> being misinterpreted.
>
> There should be wording in the spec along the lines of "the Home Agent
> MUST not include the prefix information in the aggregate list in its
> router advertisements multicast on-link"
>
> On Fri, 3 Nov 2000, Charlie Perkins wrote:
>
> > Hello again,
> >
> > In Ken's note, a proposal is made for how the home agent
> > should forward relevant router advertisement information to
> > the mobile node, when the mobile node is away from its
> > home network.
> >
> > I have devised an algorithm by which a home agent can
> > delay the transmission of this information to the mobile
> > node, in hopes that the actual transmission can be avoided
> > entirely if the mobile node might send a Binding Update
> > to the home agent.  In that case, the home agent could
> > include all the relevant information in the Binding
> > Acknowledgement.
> >
> > Item 2 is "What triggers a home agent to send router"
> >
> > Ken suggested:
> >
> > > Item 2 (perhaps replace similar text in section 9.7)
> > > ====================================================
> > >
> > > A home agent serving a mobile node SHOULD construct and
> > > tunnel to the mobile node a new Router Advertisement when
> > > any of the following conditions occur:
> > >
> > >   o A valid or preferred lifetime of a prefix in the
> > >     aggregate list of prefixes is suddenly reduced to
> > >     less than HomeRtrAdvInterval.
> > >
> > >   o The state of the flags for a prefix in the aggregate
> > >     list changes.
> > >
> > >   o A new prefix is created in the aggregate list.
> > >
> > > The home agent constructs a new Router Advertisement message
> > > containing no options other than the Prefix Information options
> > > describing the prefixes for which one of the conditions above
> > > has occurred since the last Router Advertisement tunneled to and
> > > acknowledged by the mobile node.
> > >
> > > In addition, the home agent MUST send a router advertisement
> > > with all prefixes in the aggregate list to the mobile node at
> > > least once per HomeRtrAdvInterval and upon receipt of a valid
> > > Router Solicitation from the mobile node.
> > >
> > > The home agent MAY (SHOULD?) rate limit the frequency at which it
> > > sends Router Advertisements to the mobile node by delaying
transmission
> > > until receipt of a Binding Update option from the mobile node.
> > > When multiple conditions occur at or near the same time, the
> > > home agent SHOULD attempt to combine them into a single Router
> > > Advertisement message to the mobile node.
> >
> > Instead of a specific rate-limiting feature, I suggest the following
> > algorithm:
> >
> > ===== How to send router advertisements to mobile nodes.
> >
> > - If a mobile node sends a solicitation, answer with everything.
> >
> > - If a prefix changes state in a way that causes a mobile node's
> >   address to go deprecated, send an advertisement right away.
> >
> > - If the mobile node's binding expires before the advertised
> >   Preferred Lifetime, do not schedule the advertisement.
> >   The mobile node will get the revised information in its next
> >   Binding Acknowledgement.
> >
> > - If a prefix is added, or if it changes in any way that does not
> >   cause the mobile node's address to go deprecated, ensure that
> >   a transmission is scheduled at time RAND_ADV_DELAY in the future.
> >
> > - If a prefix advertisement is scheduled, and a Binding
> >   Update arrives, perform that advertisement and include
> >   the information in a Router Advertisement that has the
> >   Binding Acknowledgement as a Destination Option.  Remove
> >   the future scheduled advertisement.
> >
> > ===== How to compute RAND_ADV_DELAY, the offset from the
> >       current time for the scheduled transmission
> >
> > If there is a transmission already scheduled, then
> >  if the current RAND_ADV_DELAY would cause another
> >  transmission BEFORE the Preferred Lifetime of the
> >  mobile node's home address derived from the prefix
> >  whose advertisement information has changed, then
> >                add the new information to be transmitted
> >                to the existing scheduled transmission
> >                -- return.
> >           otherwise,
> >                continue with the following computation,
> >                and add the data from the existing scheduled
> >                transmission to the newly scheduled transmission,
> >               deleting the previously scheduled transmission
> >                event.
> >
> > If the mobile node's binding expires after the Preferred
> > Lifetime, then compute
> >            MAX_SCHEDULE_DELAY ==
> >                      min (MAX_PFX_ADV_DELAY, Preferred Lifetime)
> > for the newly advertised Preferred Lifetime.
> > Then compute RAND_ADV_DELAY =
> >              MinRtrAdvInt + rand()*{MAX_SCHEDULE_DELAY - MinRtrAdvInt}
> >
> > ===================================================
> >
> > Regards,
> > Charlie P.
> >
>
> -------------------------------------------------------------------
> John Leser                      UNH InterOperability Lab
> IP/Routing Consortium Engineer  Morse Hall, 39 College Rd, Room 332
> Tel: (603) 862-0090 (8-5 EST)   Durham, NH 03824-3525
> Fax: (603) 862-1761             Web: www.iol.unh.edu
> -------------------------------------------------------------------


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov  6 14:04:45 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26704
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Nov 2000 14:04:45 -0500 (EST)
Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0BAA@standards.nortelnetworks.com>; Mon, 6 Nov 2000 13:46:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 80280 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 13:46:40 -0500
Received: from iol.unh.edu (mars.iol.unh.edu) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBB0BA8@standards.nortelnetworks.com>; Mon, 6 Nov 2000 13:46:40
          -0500
Received: from localhost (jfl@localhost) by iol.unh.edu (8.9.3/8.9.3) with
          ESMTP id OAA05529; Mon, 6 Nov 2000 14:04:53 -0500 (EST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved-By:  "John F. Leser" <jfl@IOL.UNH.EDU>
Message-ID:  <Pine.SGI.4.20.0011061403510.29946-100000@mars.iol.unh.edu>
Date:         Mon, 6 Nov 2000 14:04:53 -0500
Reply-To: "John F. Leser" <jfl@iol.unh.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "John F. Leser" <jfl@iol.unh.edu>
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home network renumb
              ering
X-To:         "Powell, Ken" <Ken.Powell@compaq.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <C99A689B0CB9D111AF3F0000F8062CCD08FB83B6@zkoexc2.zko.dec.com>

Ken,

Giving it more thought, I agree - better not to include the information.

On Mon, 6 Nov 2000, Powell, Ken wrote:

> Hi John,
>
> I had originally intended to copy the R bit and full IP address
> as you suggested. When I reread the definition of the R bit in
> section 6.2 again, I noticed:
>
>   "When set, indicates that the prefix field, in addition
>    to advertising the indicated prefix, contains a
>    complete IP address of the sending router."
>                               ==============
>
> Copying the R bit and its associated IP address from another
> router would violate this definition. In addition, section 10.17
> indicated that a mobile node does the following with this field:
>
>     -  If the Home Agents List entry for the link-local address of
>        the home agent sending this Advertisement was not deleted as
>        described above, determine any global address(es) of the home
>        agent based on each Prefix Information option received in
>        this Advertisement in which the Router Address (R) bit is set
>        (Section 6.2).  For each such global address determined from
>        this Advertisement, add this global address to the list of
>        global addresses for this home agent in this Home Agents List
>        entry.                ===============
>
> Once again, this would be broken if we passed the R bit and the
> IP address of another router.
>
> I suppose special processing for a tunneled router advertisement
> could be defined, but I don't see any way for a mobile node to tell
> which of multiple possible routers on the home network a particular
> address belongs to.
>
> Ken
>

-------------------------------------------------------------------
John Leser                      UNH InterOperability Lab
IP/Routing Consortium Engineer  Morse Hall, 39 College Rd, Room 332
Tel: (603) 862-0090 (8-5 EST)   Durham, NH 03824-3525
Fax: (603) 862-1761             Web: www.iol.unh.edu
-------------------------------------------------------------------


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov  7 03:17:07 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23418
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Nov 2000 03:17:07 -0500 (EST)
Received: from standards (47.234.32.16:2098) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1034@standards.nortelnetworks.com>; Tue, 7 Nov 2000 2:58:27 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 81829 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Nov 2000 02:58:26 -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB1031@standards.nortelnetworks.com>; Tue, 7 Nov 2000 2:58:26
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eA78ESb37300; Tue, 7 Nov 2000 09:14:28 +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 JAA17559; Tue, 7 Nov 2000 09:14: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.9.3/8.9.3) with
          ESMTP id JAA46009; Tue, 7 Nov 2000 09:15:51 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011070815.JAA46009@givry.rennes.enst-bretagne.fr>
Date:         Tue, 7 Nov 2000 09:15:51 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home
              networkrenumbering
X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
X-cc:         Mattias Pettersson <mattias.pettersson@era.ericsson.se>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Mon, 06 Nov 2000 09:33:50 PST. 
              <3A06EB7E.2F0768F6@iprg.nokia.com>

 In your previous mail you wrote:

   > The issue is what happens if the home link is renumbered when the MN is
   > stopped. In fact this depends on how the MN knows its home prefix(es):
   > ...

   One is left to wonder if there are any intelligent alternatives!

   I propose that the protocols and algorithms and procedures for getting
   an initial IPv6 home address allocated to a mobile node should all
   be declared out of scope, or otherwise we'll never get finished with
   the spec.

=> I agree, it is matter of configuration/management then it has nothing
to do with the protocol itself.

   > I've studied the thread above slightly and am a bit curious on
   > the effects of the new additions to the I-D below. It's still
   > the bootstrapping procedure which is of most interest; the
   > renumbering phase is a special case of the former. So: how does
   > the MN find it's home addresses and it's home agents?

   Likewise, I sincerely hope that these questions can be declared
   out of scope for the current draft.  On the other hand, I think it's
   a great discussion.

=> idem

   > Note that MN doesn't have a Home Address before step 5.

   Presumably, that would mean that the protocol you design would
   use a link-local address up until that point.

=> DNS, DHCP, AAA, ... can be done with a care-of address or a limited
scope address (more site-local than link-local but it depends on the
existence of link proxies/relays/...`

   > If home network renumbering occurs, while the MN is away from home, HA
   > normally takes care of informing the MN about new home prefixes. The MN
   > would run step 4-8 to synchronize with the renumbering.

   I'm not disagreeing with you, but my objective is to get the draft
   done, and making such dependencies for resynchronization purposes
   would be detrimental to that objective.

=> renumbering is a rare and long duration event then to survive to
very long (ie. in months) down periods is IMHO out of the scope of
the mobile IPv6 document.

   I don't think a mobile node which is currently off-link can bootstrap
   from zero.

=> I don't understand what is exactly from zero... It can't work with
strictly zero-knowledge, for instance for the authentication phase
of IPsec, but a certificate with a suitable SubjectName is enough.

   It has to at least have a security association with the
   home agent, and that has to depend on an IPv6 address, so you need to
   have an IPv6 address.  We can all try to design a better bootstrapping
   mechanism, which would clearly depend on finding new ways to identify
   a mobile node (other than using its home address).

=> of course a NAI is a better way to identify the mobile node but
it is more a security issue than a mobile IPv6 one.

   It took a year to standardize the Mobile IPv4 NAI extension, and there
   are still questions coming up on it.  My goal is to get a new Mobile IPv6
   Internet Draft done this week.  I hope we don't have to go down the
   path of specifying off-link bootstrapping from zero.

=> just put this (or keep this) out of scope.

   > What we need at this stage is a new fall-back level, where the MN can
   > find it's home prefix independently of IP. So this is where AAA comes
   > in? MN would only need to know it's name (NAI?). Everything else can be
   > resolved from this.

   Agreed -- but next year, not this one.

=> this should be in an AAA for mobile IPv6 document!

Thanks

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov  7 03:35:35 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01490
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Nov 2000 03:35:34 -0500 (EST)
Received: from standards (47.234.32.16:2098) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB109E@standards.nortelnetworks.com>; Tue, 7 Nov 2000 3:17:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 81965 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Nov 2000 03:17:29 -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB109C@standards.nortelnetworks.com>; Tue, 7 Nov 2000 3:17:28
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eA78XMb25107; Tue, 7 Nov 2000 09:33: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 JAA18106; Tue, 7 Nov 2000 09:33:21 +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.9.3/8.9.3) with
          ESMTP id JAA46091; Tue, 7 Nov 2000 09:34:45 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011070834.JAA46091@givry.rennes.enst-bretagne.fr>
Date:         Tue, 7 Nov 2000 09:34:44 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Tue, 07 Nov 2000 01:11:39 +1100. 
              <4B6BC00CD15FD2119E5F0008C7A419A50C613D8D@eaubrnt018.epa.ericsson.se>

 In your previous mail you wrote:

        => There is a close relationship between stateless
        configuration and DAD.

=> this is not true, the only relationship is they share the same document.
DAD is in fact a fully independent function and may (in fact MUST) be
used for statefull configuration too (aka DHCPv6).

        Since MIPv6 implicitly assumes the use of stateless address
        autoconfiguration.

=> this is not true! Mobile IPv6 is supposed to work with stateful
autoconf too (but as DHCPv6 is not yet ready I can't prove it today).

        If you believe that this is a special case then I can pick
        many parts of the spec where there are underlying assumptions
        about certain types of media.

=> these assumptions should be explicit and minimal.

   > To summary: the mobile IPv6 document must NOT do the assumption that
   > cellular == wireless == mobility!
   >
        => I'm not sure where you read that in what I'm saying. BTW this
        issue is irrelevant for cellular and is not specific for wireless
        systems.

=> On a common wired system you can't move from a link to another link
without a reliable indication from layer 2 like a carrier loss followed
by a restart sequence. Even Ethernet is supposed to negociate speed
and duplex when you attach a device to a link. The only kind of systems
where you should have transparent movement from a link to another one is
the cellular LAN one.

   > gain cellular != wireless != mobility

        => I know. I don't see where you read the oppsite of that in
        what I'm saying.

=> because the context where your proposal has a meaning is the cellular
one even if you don't say this and because I am really tired to see
mobile IPv6 implementations which don't support multihomed (multi-interface)
hosts.

   > PS: the simplest (and cleanest) way to solve this issue is to write
   > an IPv6-over-foo document about IEEE 802.11-like networks. The DAD
   > behavior will be a link property and it won't be applicable to
   > IEEE 802.3 networks for instance.

        => That's one way of doing it. But of course it has to be done
        for each case. I don't see a major problem with that as long
        as something is done about it. It is only a problem when
        mobility is considered.

=> mobility is an important property of 802.11-like links then
it is natural IMHO to take mobility into account in an IPv6-over-802.11
document. Today we assume that 802.11 is like 802.3 and this discussion
proves it is not true...

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov  7 05:39:20 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23877
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Nov 2000 05:39:20 -0500 (EST)
Received: from standards (47.234.32.16:2098) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1169@standards.nortelnetworks.com>; Tue, 7 Nov 2000 5:21:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 82225 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Nov 2000 05:21:19 -0500
Received: from ish7.ericsson.com.au (203.61.155.111:40852) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB1167@standards.nortelnetworks.com>; Tue, 7 Nov 2000 5:21:18
          -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id VAA15731 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 7 Nov 2000 21:34:10
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id VAA12039 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 7 Nov 2000 21:36:53
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <V42TXJTD>; Tue, 7 Nov 2000 21:37:06 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613DA5@eaubrnt018.epa.ericsson.se>
Date:         Tue, 7 Nov 2000 21:36:59 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>  In your previous mail you wrote:
>
>         => There is a close relationship between stateless
>         configuration and DAD.
>
> => this is not true, the only relationship is they share the same
> document.
> DAD is in fact a fully independent function and may (in fact MUST) be
> used for statefull configuration too (aka DHCPv6).
>
        => I can't see how this is not true !
        If you statelessly autoconfigure yourself with an address
        then you _MUST_ do DAD. It is certainly not a coincidence
        that they are in the same RFC.

>         Since MIPv6 implicitly assumes the use of stateless address
>         autoconfiguration.
>
> => this is not true! Mobile IPv6 is supposed to work with stateful
> autoconf too (but as DHCPv6 is not yet ready I can't prove it today).
>
        => I realise that it works for both. But in many situations where
        time matters you would rather use stateless address configuration.
        Of course the fact that you have to do DAD (in some links) slows
        things down.

>         If you believe that this is a special case then I can pick
>         many parts of the spec where there are underlying assumptions
>         about certain types of media.
>
> => these assumptions should be explicit and minimal.
>
        => Well, they should be and they are. So if we add DAD as
        another case that might be widely used I don't think it would
        do any harm to the spec. As I said it is only a problem with
        mobilty therefore it is certainly relevant to the MIPv6 spec.
        Do you really see any harm done by clarifying this ?

>    > To summary: the mobile IPv6 document must NOT do the assumption that
>    > cellular == wireless == mobility!
>    >
>         => I'm not sure where you read that in what I'm saying. BTW this
>         issue is irrelevant for cellular and is not specific for wireless
>         systems.
>
> => On a common wired system you can't move from a link to another link
> without a reliable indication from layer 2 like a carrier loss followed
> by a restart sequence.
>
        => You also have L2 indications in a wireless system clearly.
        They may not be identical but certainly similar.

> Even Ethernet is supposed to negociate speed
> and duplex when you attach a device to a link. The only kind of systems
> where you should have transparent movement from a link to another one is
> the cellular LAN one.
>
        => Cellular systems and LANs are two completely different systems.
        You also have L2 indications in these systems in a similar
        way (not the same of course) as you would on Ethernet L2.

>    > gain cellular != wireless != mobility
>
>         => I know. I don't see where you read the oppsite of that in
>         what I'm saying.
>
> => because the context where your proposal has a meaning is the cellular
> one even if you don't say this
>
        => That's not true at all. If I was only worried about a cellular
system
        I wouldn't bring this issue up. I've mentioned this before, the IPv6
        based cellular systems I'm aware of do not use DAD.
        Therefore it is not a concern of these systems.

> and because I am really tired to see
> mobile IPv6 implementations which don't support multihomed
> (multi-interface)
> hosts.
>
        => I really can't see how this is relevant to cellular.
        Any terminal can have multiple interfaces.
        If implementations do not support them there are
        probably other reasons and you could check with
        implementors for that.

        Regards,
        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov  7 07:51:42 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20177
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Nov 2000 07:51:42 -0500 (EST)
Received: from standards (47.234.32.16:1032) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB11FF@standards.nortelnetworks.com>; Tue, 7 Nov 2000 7:33:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 82420 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Nov 2000 07:33:35 -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB11FD@standards.nortelnetworks.com>; Tue, 7 Nov 2000 7:33:34
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eA7CnIb24276; Tue, 7 Nov 2000 13:49:18 +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 NAA27126; Tue, 7 Nov 2000 13:49:16 +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.9.3/8.9.3) with
          ESMTP id NAA47433; Tue, 7 Nov 2000 13:50:40 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011071250.NAA47433@givry.rennes.enst-bretagne.fr>
Date:         Tue, 7 Nov 2000 13:50:40 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Tue, 07 Nov 2000 21:36:59 +1100. 
              <4B6BC00CD15FD2119E5F0008C7A419A50C613DA5@eaubrnt018.epa.ericsson.se>

 In your previous mail you wrote:

   >  In your previous mail you wrote:
   >
   >         => There is a close relationship between stateless
   >         configuration and DAD.
   >
   > => this is not true, the only relationship is they share the same
   > document.
   > DAD is in fact a fully independent function and may (in fact MUST) be
   > used for statefull configuration too (aka DHCPv6).
   >
           => I can't see how this is not true !
           If you statelessly autoconfigure yourself with an address
           then you _MUST_ do DAD.

=> this is the same for statefull autoconfigure too.

           It is certainly not a coincidence that they are in the same RFC.

=> they are in the same RFC because DAD is for stateless and statefull
autoconf, the stateless part was ready and the statefull one was not
(in fact this is not yet ready today). The RFC is not only about
stateless autoconf, it is about shared part (mainly DAD) and interactions
between the two modes too. Just ask authors...

   > => On a common wired system you can't move from a link to another link
   > without a reliable indication from layer 2 like a carrier loss followed
   > by a restart sequence.
   >
           => You also have L2 indications in a wireless system clearly.
           They may not be identical but certainly similar.

=> this depends on the wireless system. Some have real carrier detections
and some have nothing, for instance the non-standard ad hoc mode by Lucent
for 802.11 (which can be considered as a cellular LAN if we need a
definition by example).

           => Any terminal can have multiple interfaces.

=> it should...

           If implementations do not support them there are
           probably other reasons and you could check with
           implementors for that.

=> I've checked. For too many of them to test mobility you have just
to unplug your RJ45 Ethernet and to plug it to another link. This is
supposed to model some 802.11 systems (but fortunately they have in
general a more clever way to work :-)...
It is this limited view of what is mobility which makes me very tired
and I believe our DAD discussion is too marked by that. This is why my
first remark was about the context: with it we can know if the DAD issue
is a general one or it is only for some applications (real-time) on a
special kind of links (what I have called cellular LANs). In both cases
it is useful to discuss (a special case issue is still an issue) but
a general issue should be in the general document (ie. can slow it down)
and a specific one should be addressed in a specific document.

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov  7 08:40:50 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09549
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Nov 2000 08:40:50 -0500 (EST)
Received: from standards (47.234.32.16:1032) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB131F@standards.nortelnetworks.com>; Tue, 7 Nov 2000 8:22:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 82786 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Nov 2000 08:22:44 -0500
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBB131D@standards.nortelnetworks.com>; Tue, 7 Nov 2000 8:22:44
          -0500
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP
          id eA7DcrZ14612; Tue, 7 Nov 2000 14:38:53 +0100 (MET)
Received: from era.ericsson.se by era-t.ericsson.se
          (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id OAA05011; Tue, 7 Nov 2000 14:38:53
          +0100
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
References: <200011070815.JAA46009@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Mattias Pettersson <mattias.pettersson@ERA.ERICSSON.SE>
Message-ID:  <3A0805EA.3F1692D4@era.ericsson.se>
Date:         Tue, 7 Nov 2000 14:38:50 +0100
Reply-To: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Radio Systems AB
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home
              networkrenumbering
X-To:         Francis Dupont <Francis.Dupont@enst-bretagne.fr>
X-cc:         "Charles E. Perkins" <charliep@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi all,

Francis Dupont wrote:

>  In your previous mail you wrote:
>
>    > The issue is what happens if the home link is renumbered when the MN is
>    > stopped. In fact this depends on how the MN knows its home prefix(es):
>    > ...
>
>    One is left to wonder if there are any intelligent alternatives!
>
>    I propose that the protocols and algorithms and procedures for getting
>    an initial IPv6 home address allocated to a mobile node should all
>    be declared out of scope, or otherwise we'll never get finished with
>    the spec.

I'd like to open up for a simple procedure, see below.

>    > Note that MN doesn't have a Home Address before step 5.
>
>    Presumably, that would mean that the protocol you design would
>    use a link-local address up until that point.
>
> => DNS, DHCP, AAA, ... can be done with a care-of address or a limited
> scope address (more site-local than link-local but it depends on the
> existence of link proxies/relays/...`

My idea was to use the care-of address until the MN can determine its home
address. The point I want to make in the draft is to allow the MN to create its
home addresses both at initial bootstrapping on a foreign network or after a
home network renumbering while it was disconnected.

As I see it the MN MAY form its home addresses by the method stated in RAs on
the home link. Other alternatives are AAA or whatever, but I believe we should
try to allow autoconfiguration of an MN that may never attach directly to its
home network. What is needed for autoconfiguration is an RA from the home link
received by the MN; the rest is specified in the RA. The HA can send this to the
MN, can't it? So I bring back my scenario:

1. The MN finds out its home prefix.
2. MN performs DHAAD to find unicast address of an HA.
3. MN sends RS to HA.
4. HA sends RA with prefix list to MN.
5. MN builds Home Addresses for all prefixes, by using address method
stated in prefix info.
6. MN registers each Home Address.
7. HA might help in address configuration (e.g. DAD)
8. DNS should be updated, depending on address configuration method (it
should be done by the MN at this point, not earlier, IMO).

Ok. Let's agree on leaving the big issues out of scope. Step 1 should be in a
different document. Forget if I mentioned 8.

Still a remark of the configuration alternatives as was suggested could be
useful in the draft:
Home Prefix (needed to find Home Agents) conf alts:
1A. Manual:
    - won't survive home network renum when MN is off.
1B. Always start home or user interaction (button...):
    - same, plus need to start at home, a difficult demand
1C. AAA:
    - will survive anything.

Home Address conf alts:
2A. Manual:
    - not the best idea. MN can't check its Home Address for DAD.
    - What is the relationship between a manual address and the renumbered
autoconfigured address?
2B. Autoconf by RA from Home Link (either directly from Home Link or tunneled by
HA):
    - MN will be configured just as if it was home.
2C. AAA:
    - then addresses are configured and distributed by other means than IPv6 ND
autoconf (state{ful,less})
    - if renumbering occurs MN must get new address though AAA rather than RA.

What I want is to open up the possibility for the MN to go through step 2-5
without neither having a home address nor having been at home before:

Ken Powell wrote:

> Item 3
> ======
>
> 10.x Sending Router Solicitations to a Home Agent
>
> A mobile node that uses stateless address auto configuration on
> its home subnet could miss significant home subnet configuration
> changes while disconnected. Such a mobile node MAY request updated
> prefix information when it detects a possibility that its current
> home subnet address information is inaccurate by sending a Router
> Solicitation to the home agent. The mobile node must construct
> such a Router Solicitation packet as follows:
>

I want this also the first time when MN has never received an RA from its home
link.

>  -  The Source Address in the packet's IPv6 header MUST be set
>     to the mobile node's primary care-of address.
>
>  -  The packet MUST be protected by IPsec [13, 11, 12] to guard
>     against malicious Router Solicitations.  The IPsec protection
>     MUST provide sender authentication, data integrity protection,
>     and replay protection, covering the Router Solicitation.
>
>  - The packet MUST include a Home Address destination option,
>    giving the mobile node's home address for its current
>    binding.
>
>  - The packet MUST include a Binding Update destination option
>    as described in section 10.6 if a current binding does not
>    yet exist. Otherwise, it MAY include a Binding Update
>    destination option.

Here we have a problem. If the MN doesn't have a home address it can't provide
any at this point (step 3 above).

Is there a way we can leave this open for a lost MN with no home address?
However, we must still secure the protocol, of course, but we can do this
without a home address.

Are the Home Address Option and Binding Update really needed, unless the HA is
expecting an ack?


Francis wrote:

>    > If home network renumbering occurs, while the MN is away from home, HA
>    > normally takes care of informing the MN about new home prefixes. The MN
>    > would run step 4-8 to synchronize with the renumbering.
>
>    I'm not disagreeing with you, but my objective is to get the draft
>    done, and making such dependencies for resynchronization purposes
>    would be detrimental to that objective.
>
> => renumbering is a rare and long duration event then to survive to
> very long (ie. in months) down periods is IMHO out of the scope of
> the mobile IPv6 document.

We already have this feature due to the inclusion of Ken's section. I just
wanted to show you that Ken's proposal equals step 4-8 (or 3-4, giving 5-8).
This is what MIPv6 always claimed it had. I.e., nothing new.


>    I don't think a mobile node which is currently off-link can bootstrap
>    from zero.
>
> => I don't understand what is exactly from zero... It can't work with
> strictly zero-knowledge, for instance for the authentication phase
> of IPsec, but a certificate with a suitable SubjectName is enough.
>

Exactly.

>    It has to at least have a security association with the
>    home agent, and that has to depend on an IPv6 address, so you need to
>    have an IPv6 address.  We can all try to design a better bootstrapping
>    mechanism, which would clearly depend on finding new ways to identify
>    a mobile node (other than using its home address).
>
> => of course a NAI is a better way to identify the mobile node but
> it is more a security issue than a mobile IPv6 one.

You need a NAI, and a care-of address.

>
>
>    It took a year to standardize the Mobile IPv4 NAI extension, and there
>    are still questions coming up on it.  My goal is to get a new Mobile IPv6
>    Internet Draft done this week.  I hope we don't have to go down the
>    path of specifying off-link bootstrapping from zero.
>
> => just put this (or keep this) out of scope.

We only need it for step 1, which is out of scope. Still the final solution
needs it.

>
>
>    > What we need at this stage is a new fall-back level, where the MN can
>    > find it's home prefix independently of IP. So this is where AAA comes
>    > in? MN would only need to know it's name (NAI?). Everything else can be
>    > resolved from this.
>
>    Agreed -- but next year, not this one.
>
> => this should be in an AAA for mobile IPv6 document!

Very much needed. But I agree this is out of scope.

/Mattias


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov  7 13:51:52 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20070
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Nov 2000 13:51:51 -0500 (EST)
Received: from standards (47.234.32.16:1977) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB15B6@standards.nortelnetworks.com>; Tue, 7 Nov 2000 13:33:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 83631 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Nov 2000 13:33:05 -0500
Received: from zcamail03.zca.compaq.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB15B4@standards.nortelnetworks.com>; Tue, 7 Nov 2000 13:33:01
          -0500
Received: by zcamail03.zca.compaq.com (Postfix,
          from userid 12345) id C9CCB8DD; Tue,  7 Nov 2000 10:49:09 -0800 (PST)
Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net
          [16.103.129.42]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id
          CE5469D6; Tue,  7 Nov 2000 10:49:08 -0800 (PST)
Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service
          (5.5.2650.21) id <WND0LXL8>; Tue, 7 Nov 2000 13:49:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Powell, Ken" <Ken.Powell@COMPAQ.COM>
Message-ID:  <C99A689B0CB9D111AF3F0000F8062CCD08FB83B7@zkoexc2.zko.dec.com>
Date:         Tue, 7 Nov 2000 13:49:05 -0500
Reply-To: "Powell, Ken" <Ken.Powell@compaq.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Powell, Ken" <Ken.Powell@compaq.com>
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home networkrenumbe
              ring
X-To:         Mattias Pettersson <mattias.pettersson@era.ericsson.se>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Mattias,

I think you have a very important initialization concern,
primarily because it impacts the way RS's and RA's are
sent between the home agent and the mobile node. It boils
down to a question of can we assume the mobile node will
always have a home address before the first RS/RA exchange?
I hope so, because if not, the technique for sending RS/RA
is broken. Further details below (along with plenty of other
stuff).

> I'd like to open up for a simple procedure, see below.

I had asked about a similar procedure before. I believe
Charlie was thinking about adding it in an appendix as an
FYI. That made sense to me given that the procedure simply
showed how a mobile node could use existing protocol
mechanisms to initialize itself. It didn't really add
any protocol requirements. I also agree with Charlie
that we should not block the current spec to sort
out all details of initialization.

<snip>

Following your proposed list of initialization steps:

> 1. The MN finds out its home prefix.

One possible option for this was to statically configure in
the mobile node the fully qualified domain name of the home
agent's anycast address. This would allow the mobile node to:

1a. Query DNS for the home agent's anycast address.
1b. Temporarily use the prefix from the home agent's
    anycast address for the home subnet prefix.
1c. Use the temporary home subnet prefix and a globally
    unique interface id to autoconfigure a temporary home
    subnet address for the mobile node.

I'm hoping for a better technique to be defined in the
future possibly using AAA that covers IPsec requirements
as well.

> 2. MN performs DHAAD to find unicast address of an HA.
> 3. MN sends RS to HA.
> 4. HA sends RA with prefix list to MN.

Given the current method of how RS and RA are exchanged
between the mobile node and home agent, you have to have
a global scope home address for the mobile node by step 3.
You also have to have a valid binding between the mobile
node and the home agent for the home agent to return the
RA. Therefore, it makes sense for the mobile node to
send the BU option for its temporary address with the
initial RS.

> 5. MN builds Home Addresses for all prefixes, by using
>address method stated in prefix info.
> 6. MN registers each Home Address.
> 7. HA might help in address configuration (e.g. DAD)
> 8. DNS should be updated, depending on address configuration
> method (it should be done by the MN at this point, not
> earlier, IMO).
>
> Ok. Let's agree on leaving the big issues out of scope.

Would listing such steps in an appendix be OK with you?

> Forget if I mentioned 8.

Thanks, I was going to ask about that.

> Still a remark of the configuration alternatives as was
> suggested could be useful in the draft:

I agree. But I'm concerned this may take quite a bit of
effort to agree upon the details. See example questions below.

> Home Prefix (needed to find Home Agents) conf alts:
> 1A. Manual:
>     - won't survive home network renum when MN is off.
> 1B. Always start home or user interaction (button...):
>     - same, plus need to start at home, a difficult demand
> 1C. AAA:
>     - will survive anything.

I have no idea what AAA does for us on this. I wouldn't
assume it could be used as an alternative to stateless
address autoconfiguration or DHCPv6.

Would you add the following as another option?

  1D. Store prefix in DNS.
       - Must assume a prefix length.

>
> Home Address conf alts:

Why have two separate lists for home prefix and home address?
It seems to me the technique for determining the home address is
closely tied to the method for determining home prefix.

> 2A. Manual:
>     - not the best idea. MN can't check its Home Address
>       for DAD.

DAD must be used even with manual address configuration.

>     - What is the relationship between a manual address and
>       the renumbered autoconfigured address?
> 2B. Autoconf by RA from Home Link (either directly from Home
>     Link or tunneled by HA):
>     - MN will be configured just as if it was home.
> 2C. AAA:
>     - then addresses are configured and distributed by other
>       means than IPv6 ND autoconf (state{ful,less})
>     - if renumbering occurs MN must get new address though
>        AAA rather than RA.

Could AAA be defined to work with stateless address
autoconfiguration or DHCPv6 instead of as an alternative?
Perhaps AAA could somehow bootstrap these other mechanisms.
I know nothing about AAA beyond the idea that it provides
information necessary to establish a security association
between the home agent and the mobile node.

>
> What I want is to open up the possibility for the MN to go
> through step 2-5 without neither having a home address nor
> having been at home before:

I don't think we can do this without changing the way RS's and
RA's are sent. I think this issue is very important to resolve
now because a change later to the method for sending RS's and
RA's won't be upward compatible.

>
> Ken Powell wrote:
>
> > Item 3
> > ======
> >
> > 10.x Sending Router Solicitations to a Home Agent
> >
> > A mobile node that uses stateless address auto configuration on
> > its home subnet could miss significant home subnet configuration
> > changes while disconnected. Such a mobile node MAY request updated
> > prefix information when it detects a possibility that its current
> > home subnet address information is inaccurate by sending a Router
> > Solicitation to the home agent. The mobile node must construct
> > such a Router Solicitation packet as follows:
> >
>
> I want this also the first time when MN has never received an
> RA from its home link.

This is one of the cases I was thinking of when I wrote the clause
"when it detects a possibility that its current home subnet address
information is inaccurate". I don't have any problem if Charlie wants
to add this as an example.

>
> >  -  The Source Address in the packet's IPv6 header MUST be set
> >     to the mobile node's primary care-of address.
> >
> >  -  The packet MUST be protected by IPsec [13, 11, 12] to guard
> >     against malicious Router Solicitations.  The IPsec protection
> >     MUST provide sender authentication, data integrity protection,
> >     and replay protection, covering the Router Solicitation.
> >
> >  - The packet MUST include a Home Address destination option,
> >    giving the mobile node's home address for its current
> >    binding.
> >
> >  - The packet MUST include a Binding Update destination option
> >    as described in section 10.6 if a current binding does not
> >    yet exist. Otherwise, it MAY include a Binding Update
> >    destination option.
>
> Here we have a problem. If the MN doesn't have a home address
> it can't provide any at this point (step 3 above).

Agreed. This is a problem for both the RS and RA. The way they
are exchanged requires that the mobile node have at least one
home address first. Some months back, I asked if it would be
reasonable for the mobile node to generate a temporary address
(very short lifetime) to get past this exchange. Such an
address would only be allowed if it was based on a globally
unique interface id.

> Is there a way we can leave this open for a lost MN with no
> home address?

The only way I could think of was to always tunnel the RA and
RS per RFC 2473 instead of using the home address option
and the routing header. I tried to think of ways to
initialize using link-local addresses or the unspecified
address for the mobile node, but doing so without a tunneled
IPv6 header violated the base spec.

The problem with switching to RFC 2473 tunneling is that
we would have to clearly define how to secure the message,
how to associate a tunneled message to a specific binding,
what to do if no binding exists, and how to attach a binding
update/acknowledge option to a tunneled RS/RA.

It seemed much simpler and less disruptive to the current
spec to let the mobile node generate a temporary address.

> However, we must still secure the protocol, of course, but we
> can do this
> without a home address.
>
> Are the Home Address Option and Binding Update really needed,
> unless the HA is
> expecting an ack?

Hmm, I hadn't thought of this. If I understand you correctly,
your suggesting the mobile node send the RS directly from
its care-of address to the home agent with no home address
option? I suppose it could work, but I'm not comfortable
with it. This implies to me that the home agent returns
the RA back to the mobile node's care-of address with no
routing header. The home agent would normally put the mobile
node's home address in the routing header, but the mobile
node doesn't have a home address configured yet. This
solution feels to me like exchanging RS's and RA's over one
interface (with the care-of address) to configure another
interface (with the home address).

Of the three options for handling RS's and RA's, my
preference is:

 1st: Keep the current mechanisms which require that the
      mobile node somehow get an initial home prefix and
      address before communication starts. Method to be
      specified later.

 2nd: Use RFC 2473 style tunneling.

 last: Exchange RS's and RA's directly between a
      the home agent and the mobile node's care-of
      address to configure the mobile node's home
      addresses.

Ken


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov  7 16:42:08 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06190
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Nov 2000 16:42:07 -0500 (EST)
Received: from standards (47.234.32.16:2257) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB16A7@standards.nortelnetworks.com>; Tue, 7 Nov 2000 16:23:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 83958 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Nov 2000 16:23:15 -0500
Received: from zcamail05.zca.compaq.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB16A5@standards.nortelnetworks.com>; Tue, 7 Nov 2000 16:23:11
          -0500
Received: by zcamail05.zca.compaq.com (Postfix,
          from userid 12345) id 5FB41943; Tue,  7 Nov 2000 13:40:05 -0800 (PST)
Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net
          [16.103.129.53]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id
          E12A32F6; Tue,  7 Nov 2000 13:40:04 -0800 (PST)
Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service
          (5.5.2650.21) id <W1TZSS7D>; Tue, 7 Nov 2000 16:39:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Powell, Ken" <Ken.Powell@COMPAQ.COM>
Message-ID:  <C99A689B0CB9D111AF3F0000F8062CCD08FB83BA@zkoexc2.zko.dec.com>
Date:         Tue, 7 Nov 2000 16:39:18 -0500
Reply-To: "Powell, Ken" <Ken.Powell@compaq.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Powell, Ken" <Ken.Powell@compaq.com>
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home network renumb
              ering
X-To:         Charlie Perkins <charliep@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Charlie,

I like the intent of your changes, but have questions
on the details. My comments are sliced in below.

Ken

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: Friday, November 03, 2000 8:40 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] How Mobile IPv6 should handle home network
> renumbering
>
>
> Hello again,
>
> In Ken's note, a proposal is made for how the home agent
> should forward relevant router advertisement information to
> the mobile node, when the mobile node is away from its
> home network.
>
> I have devised an algorithm by which a home agent can
> delay the transmission of this information to the mobile
> node, in hopes that the actual transmission can be avoided
> entirely if the mobile node might send a Binding Update
> to the home agent.  In that case, the home agent could
> include all the relevant information in the Binding
> Acknowledgement.
>
> Item 2 is "What triggers a home agent to send router"
>
> Ken suggested:
>
> > Item 2 (perhaps replace similar text in section 9.7)
> > ====================================================
> >
> > A home agent serving a mobile node SHOULD construct and
> > tunnel to the mobile node a new Router Advertisement when
> > any of the following conditions occur:
> >
> >   o A valid or preferred lifetime of a prefix in the
> >     aggregate list of prefixes is suddenly reduced to
> >     less than HomeRtrAdvInterval.
> >
> >   o The state of the flags for a prefix in the aggregate
> >     list changes.
> >
> >   o A new prefix is created in the aggregate list.
> >
> > The home agent constructs a new Router Advertisement message
> > containing no options other than the Prefix Information options
> > describing the prefixes for which one of the conditions above
> > has occurred since the last Router Advertisement tunneled to and
> > acknowledged by the mobile node.
> >
> > In addition, the home agent MUST send a router advertisement
> > with all prefixes in the aggregate list to the mobile node at
> > least once per HomeRtrAdvInterval and upon receipt of a valid
> > Router Solicitation from the mobile node.
> >
> > The home agent MAY (SHOULD?) rate limit the frequency at which it
> > sends Router Advertisements to the mobile node by delaying
> transmission
> > until receipt of a Binding Update option from the mobile node.
> > When multiple conditions occur at or near the same time, the
> > home agent SHOULD attempt to combine them into a single Router
> > Advertisement message to the mobile node.
>
> Instead of a specific rate-limiting feature, I suggest the following
> algorithm:
>
> ===== How to send router advertisements to mobile nodes.
>
> - If a mobile node sends a solicitation, answer with everything.
>
> - If a prefix changes state in a way that causes a mobile node's
>   address to go deprecated, send an advertisement right away.
>
> - If the mobile node's binding expires before the advertised
>   Preferred Lifetime, do not schedule the advertisement.
>   The mobile node will get the revised information in its next
>   Binding Acknowledgement.
>
> - If a prefix is added, or if it changes in any way that does not
>   cause the mobile node's address to go deprecated, ensure that
>   a transmission is scheduled at time RAND_ADV_DELAY in the future.

If I assume the third item takes precedence over the fourth,
then scheduling with RAND_ADV_DELAY will only occur when
the prefix is due to deprecate soon or has already deprecated.
Did I read this right?

>
> - If a prefix advertisement is scheduled, and a Binding
>   Update arrives, perform that advertisement and include
>   the information in a Router Advertisement that has the
>   Binding Acknowledgement as a Destination Option.  Remove
>   the future scheduled advertisement.
>
> ===== How to compute RAND_ADV_DELAY, the offset from the
>       current time for the scheduled transmission
>
> If there is a transmission already scheduled, then
>  if the current RAND_ADV_DELAY would cause another
>  transmission BEFORE the Preferred Lifetime of the
>  mobile node's home address derived from the prefix
>  whose advertisement information has changed, then
>                add the new information to be transmitted
>                to the existing scheduled transmission
>                -- return.
>           otherwise,
>                continue with the following computation,
>                and add the data from the existing scheduled
>                transmission to the newly scheduled transmission,
>               deleting the previously scheduled transmission
>                event.
>
> If the mobile node's binding expires after the Preferred
> Lifetime, then compute
>            MAX_SCHEDULE_DELAY ==
>                      min (MAX_PFX_ADV_DELAY, Preferred Lifetime)

This would cause all changes that happen after a prefix is
deprecated (preferred lifetime = 0) but not yet expired
(valid lifetime > 0) to be sent immediately. Would it
make sense to switch back to waiting for the next binding
update after the prefix has been deprecated? A prefix
could be in the deprecated but not yet expired state
for a few weeks during a normal renumbering.

> for the newly advertised Preferred Lifetime.
> Then compute RAND_ADV_DELAY =
>              MinRtrAdvInt + rand()*{MAX_SCHEDULE_DELAY - MinRtrAdvInt}

Is it possible for MAX_SCHEDULE_DELAY to be less than MinRtrAdvInt,
perhaps if Preferred Lifetime is very close to zero?

Ken


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov  7 17:08:23 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12008
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Nov 2000 17:08:23 -0500 (EST)
Received: from standards (47.234.32.16:2257) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB170F@standards.nortelnetworks.com>; Tue, 7 Nov 2000 16:50:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 84096 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Nov 2000 16:50:17 -0500
Received: from motgate4.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB170D@standards.nortelnetworks.com>; Tue, 7 Nov 2000 16:50:17
          -0500
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by
          motgate4.mot.com (motgate4 2.1) with ESMTP id PAA04248 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 7 Nov 2000 15:06:28
          -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116])
          by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA24047 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 7 Nov 2000 15:04:10
          -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2651.58) id
          <WMP3XPBF>; Tue, 7 Nov 2000 16:04:56 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain
Approved-By:  Roberts Philip-qa3445 <Philip_Roberts-qa3445@EMAIL.MOT.COM>
Message-ID:  <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D243@il27exm03.cig.mot.com>
Date:         Tue, 7 Nov 2000 16:04:53 -0600
Reply-To: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Subject:      [MOBILE-IP] v4 fast handoff lack of interest?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi folks,

        I'm perceiving the working group has a lack of interest in the v4
fast handoff proposals.  The v4 team did its work and produced two drafts:
draft-calhoun-mobileip-proactive-fa-02.txt
draft-elmalki-mobileip-fast-handoffs-03.txt

        There was a list of differences posted and a pointer to the design
team archive.  There were a couple of messages by people who were in the
design team as a follow-up but little other group comment.

        Raj and I are trying to discern whether the working group is a)
uninterested in making a decision about the proposals (either one is fine)
or b) uninterested in having a v4 fast handoff work item because it's not
perceived as something that's going to be used.  It's hard for us to draw
any conclusions on this without some comments.  Care to give us a sense
about it?

Thanks,
Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov  7 17:21:44 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14994
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Nov 2000 17:21:43 -0500 (EST)
Received: from standards (47.234.32.16:2257) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB177A@standards.nortelnetworks.com>; Tue, 7 Nov 2000 17:03:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 84236 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Nov 2000 17:03:41 -0500
Received: from pcsprodms11.vsmail.org (pcsprodms11.voicestream.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB1778@standards.nortelnetworks.com>; Tue, 7 Nov 2000
          17:03:40 -0500
Received: by PCSPRODMS11 with Internet Mail Service (5.5.2650.21) id
          <V9J2PCN2>; Tue, 7 Nov 2000 14:17:38 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Bilgic, Murat" <Murat.Bilgic@VOICESTREAM.COM>
Message-ID:  <EB57A58B1B1ED411B64200508B50FB0601664CED@PCSPRODMS09>
Date:         Tue, 7 Nov 2000 14:19:45 -0800
Reply-To: "Bilgic, Murat" <Murat.Bilgic@voicestream.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Bilgic, Murat" <Murat.Bilgic@voicestream.com>
Subject:      Re: [MOBILE-IP] v4 fast handoff lack of interest?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

After so many years of no significant deployment, it's very hard to show
enthusiasm for mobileIPv4. MobileIPv6 is a more interesting work item.

Murat Bilgic

> -----Original Message-----
> From: Roberts Philip-qa3445 [SMTP:Philip_Roberts-qa3445@email.mot.com]
> Sent: Tuesday, November 07, 2000 3:05 PM
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      [MOBILE-IP] v4 fast handoff lack of interest?
>
> Hi folks,
>
>         I'm perceiving the working group has a lack of interest in the v4
> fast handoff proposals.  The v4 team did its work and produced two drafts:
> draft-calhoun-mobileip-proactive-fa-02.txt
> draft-elmalki-mobileip-fast-handoffs-03.txt
>
>         There was a list of differences posted and a pointer to the design
> team archive.  There were a couple of messages by people who were in the
> design team as a follow-up but little other group comment.
>
>         Raj and I are trying to discern whether the working group is a)
> uninterested in making a decision about the proposals (either one is fine)
> or b) uninterested in having a v4 fast handoff work item because it's not
> perceived as something that's going to be used.  It's hard for us to draw
> any conclusions on this without some comments.  Care to give us a sense
> about it?
>
> Thanks,
> Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov  7 17:36:38 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19010
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Nov 2000 17:36:37 -0500 (EST)
Received: from standards (47.234.32.16:2257) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1838@standards.nortelnetworks.com>; Tue, 7 Nov 2000 17:18:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 84498 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Nov 2000 17:18:43 -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBB1836@standards.nortelnetworks.com>;
          Tue, 7 Nov 2000 17:18:43 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id PAA20172; Tue, 7 Nov 2000 15:34:50
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          OAA14576; Tue, 7 Nov 2000 14:33:38 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id OAA19468; Tue, 7 Nov 2000 14:33:35
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Patrice Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.973636258.6376.pcalhoun@nasnfs>
Date:         Tue, 7 Nov 2000 14:30:58 -0800
Reply-To: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] v4 fast handoff lack of interest?
X-To:         "Bilgic, Murat" <Murat.Bilgic@voicestream.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <EB57A58B1B1ED411B64200508B50FB0601664CED@PCSPRODMS09>

Well given 3GPP2's rather grandiose Mobile IPv4 deployment plans, perhaps that
shouldn't be much of a reason.

My opinion is that this work is necessary for next generation CDMA networks
(at the very least).

PatC
> After so many years of no significant deployment, it's very hard to show
> enthusiasm for mobileIPv4. MobileIPv6 is a more interesting work item.
>
> Murat Bilgic
>
> > -----Original Message-----
> > From: Roberts Philip-qa3445 [SMTP:Philip_Roberts-qa3445@email.mot.com]
> > Sent: Tuesday, November 07, 2000 3:05 PM
> > To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > Subject:      [MOBILE-IP] v4 fast handoff lack of interest?
> >
> > Hi folks,
> >
> >         I'm perceiving the working group has a lack of interest in the v4
> > fast handoff proposals.  The v4 team did its work and produced two drafts:
> > draft-calhoun-mobileip-proactive-fa-02.txt
> > draft-elmalki-mobileip-fast-handoffs-03.txt
> >
> >         There was a list of differences posted and a pointer to the design
> > team archive.  There were a couple of messages by people who were in the
> > design team as a follow-up but little other group comment.
> >
> >         Raj and I are trying to discern whether the working group is a)
> > uninterested in making a decision about the proposals (either one is fine)
> > or b) uninterested in having a v4 fast handoff work item because it's not
> > perceived as something that's going to be used.  It's hard for us to draw
> > any conclusions on this without some comments.  Care to give us a sense
> > about it?
> >
> > Thanks,
> > Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov  7 19:29:41 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17299
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Nov 2000 19:29:40 -0500 (EST)
Received: from standards (47.234.32.16:4633) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1967@standards.nortelnetworks.com>; Tue, 7 Nov 2000 19:11:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 84907 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Nov 2000 19:11:36 -0500
Received: from ish7.ericsson.com.au (203.61.155.111:51123) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB1965@standards.nortelnetworks.com>; Tue, 7 Nov 2000
          19:11:35 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA14506 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 8 Nov 2000 11:24:28
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA07504 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 8 Nov 2000 11:27:12
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <V42TX44J>; Wed, 8 Nov 2000 11:27:25 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613DAB@eaubrnt018.epa.ericsson.se>
Date:         Wed, 8 Nov 2000 11:27:24 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home networkrenumbe
              ring
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Could AAA be defined to work with stateless address
autoconfiguration or DHCPv6 instead of as an alternative?
Perhaps AAA could somehow bootstrap these other mechanisms.
I know nothing about AAA beyond the idea that it provides
information necessary to establish a security association
between the home agent and the mobile node.

=> Actually I believe the security association
is between the MN and AAAH.

While there are no messages defined yet for
IPv6 AAA. You could envision a scenario
where having your NAI, and the shared secret with
your AAAH would be a sufficient start to request
pretty much anything from your home network.

So if you have your NAI and your shared secret with
AAAH, the rest is basic protocol design IMO.
You can request a home address, then discover
a HA (better than requesting a HA as well IMO)
or request home address and a HA.


Regards,
Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov  8 00:49:46 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17777
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Nov 2000 00:49:45 -0500 (EST)
Received: from standards (47.234.32.16:1571) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1A8D@standards.nortelnetworks.com>; Wed, 8 Nov 2000 0:31:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 85300 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 00:31:35 -0500
Received: from ish7.ericsson.com.au (203.61.155.111:59919) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB1A8B@standards.nortelnetworks.com>; Wed, 8 Nov 2000 0:31:33
          -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id QAA11458; Wed, 8
          Nov 2000 16:44:22 +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA17878; Wed, 8
          Nov 2000 16:47:05 +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <V42TX9AZ>; Wed, 8 Nov 2000 16:47:18 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613DB5@eaubrnt018.epa.ericsson.se>
Date:         Wed, 8 Nov 2000 16:47:16 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup
              port in
              IPv6"draft]
X-To:         Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>            => I can't see how this is not true !
>            If you statelessly autoconfigure yourself with an address
>            then you _MUST_ do DAD.
>
> => this is the same for statefull autoconfigure too.
>
        => That's fine, but it doesn't make the statement
        untrue. I'm considering the stateless part only.
        So a subset of the DAD use.


>    > => On a common wired system you can't move from a link to another
> link
>    > without a reliable indication from layer 2 like a carrier loss
> followed
>    > by a restart sequence.
>    >
>            => You also have L2 indications in a wireless system clearly.
>            They may not be identical but certainly similar.
>
> => this depends on the wireless system. Some have real carrier detections
> and some have nothing, for instance the non-standard ad hoc mode by Lucent
> for 802.11 (which can be considered as a cellular LAN if we need a
> definition by example).
>
>            => Any terminal can have multiple interfaces.
>
> => it should...
>
>            If implementations do not support them there are
>            probably other reasons and you could check with
>            implementors for that.
>
> => I've checked. For too many of them to test mobility you have just
> to unplug your RJ45 Ethernet and to plug it to another link. This is
> supposed to model some 802.11 systems (but fortunately they have in
> general a more clever way to work :-)...
> It is this limited view of what is mobility which makes me very tired
> and I believe our DAD discussion is too marked by that. This is why my
> first remark was about the context: with it we can know if the DAD issue
> is a general one or it is only for some applications (real-time) on a
> special kind of links (what I have called cellular LANs). In both cases
> it is useful to discuss (a special case issue is still an issue) but
> a general issue should be in the general document (ie. can slow it down)
> and a specific one should be addressed in a specific document.
>
        => Well there are considerations for media specific characteristics
        in the spec .... anyway the aim of my mail is to bring the issue
        to the authors' attention again since a new revision is coming
        out. I'm not trying to delay it, just to get the comments in on
time.
        I think a note on DAD would be sufficient. Even if it's in the
appendix.
        Just so people are aware of the dependencies between the two
        specs. I don't think adding that is a major job that would delay
        the spec.

        Regards,
        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov  8 11:59:16 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29232
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Nov 2000 11:59:15 -0500 (EST)
Received: from standards (47.234.32.16:4977) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1F5F@standards.nortelnetworks.com>; Wed, 8 Nov 2000 11:41:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 86843 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 11:41:06 -0500
Received: from motgate4.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB1F5D@standards.nortelnetworks.com>; Wed, 8 Nov 2000 11:41:06
          -0500
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by
          motgate4.mot.com (motgate4 2.1) with ESMTP id JAA03345 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 8 Nov 2000 09:57:19
          -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116])
          by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA23891 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 8 Nov 2000 09:57:19
          -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2651.58) id
          <WMP3XZ4G>; Wed, 8 Nov 2000 10:57:19 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain; charset="ISO-8859-1"
Approved-By:  Roberts Philip-qa3445 <Philip_Roberts-qa3445@EMAIL.MOT.COM>
Message-ID:  <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D256@il27exm03.cig.mot.com>
Date:         Wed, 8 Nov 2000 10:57:16 -0600
Reply-To: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Subject:      Re: [MOBILE-IP] v4 fast handoff lack of interest?
X-To:         "M. Scott Corson" <mscorson@ix.netcom.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Thanks for the comments.  The one point I want to make at this time in
response to what you've written and what Haseeb asked before is that by
choosing a draft from among these two presently does *NOT* imply that draft
is set in stone.  It would become the working group item which is of course
open to improvements.

> ----------
> From:         M. Scott Corson
> Sent:         Thursday, November 9, 2000 12:47 AM
> To:   Roberts Philip-qa3445; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: [MOBILE-IP] v4 fast handoff lack of interest?
>
> >        Raj and I are trying to discern whether the working group is a)
> >uninterested in making a decision about the proposals (either one is
> fine)
> >or b) uninterested in having a v4 fast handoff work item because it's not
> >perceived as something that's going to be used.  It's hard for us to draw
> >any conclusions on this without some comments.  Care to give us a sense
> >about it?
> >
> >Thanks,
> >Phil
> >
>
> Phil,
>
> Just on time we have some comments.....and you thought that no one cared
> :-)
>
> We feel that the FA assisted approach has a number of advantages over the
> fast handoff approach. Most of the arguments, however, have been made
> already in this list (see McCann's "[MOBILE-IP] Differences between the
> two
> MIPv4 handoff approaches" for an example). The most important arguments
> against Fast Handoff from our point of view is:
> 1. Increased signaling on the old link; which might be degrading.
> 2. Ability of the FA assisted approach to support vanilla RFC2002 MIP
> clients.
>
> We do, however, feel that the FA assisted proposal can be improved.
>
> Please consider the following modifications:
> Lets use the basic idea of Source and Destination Trigger but also support
> the following:
> 1. A temporary tunnel between old FA and new FA (whether GFA/AFA is used
> or
> not)
> 2. The creation of this temporary tunnel to be based on BR/BU/BUAck
> messages (see below)
> 3. Regional/Hierarchical mobile IP signaling to be optionally used in
> parallel to the 1,2
>
> In more particular:
>
>
>
>                                                  +-----+
>                                                  | GFA |
>                                                  +-----+
>                                                   ^  |
>                                  2b. Regional Reg |  | 3b. Regional Reply
>                                                   |  |
>                                                   |  v
>                       +-----+ 1. Binding Update  +-----+
>                       |     | -----------------> |     |
>                       | oFA | 2. Binding Ack     | nFA |
>                       |     | <----------------- |     |
>                       +-----+                    +-----+
>
>
>                       +-----+    Movement        +-----+
>                       | MN  | - - - - - - - - -> | MN  |
>                       +-----+                    +-----+
>        Figure 4 - "source trigger" hand-off optionally using either AFA or
> GFA
>
> - 1 & 2 are mandatory messages that set a temporary (optionally
> bi-directional) tunnel between oFA and nFA
> - 2b & 3b are optional messages used if the BU includes a GFA or AFA
> address
>
>                                                  +-----+
>                                                  | GFA |
>                                                  +-----+
>                                                   ^  |
>                                  3b. Regional Reg |  | 4b. Regional Reply
>                                                   |  |
>                               1. Binding Request  |  v
>                       +-----+ <----------------  +-----+
>                       |     | 2. Binding Update  |     |
>                       | oFA | -----------------> | nFA |
>                       |     | 3.  Binding Ack    |     |
>                       +-----+ <----------------- +-----+
>
>
>                       +-----+    Movement        +-----+
>                       | MN  | - - - - - - - - -> | MN  |
>                       +-----+                    +-----+
>        Figure 5 - "target trigger" hand-off using either AFA or GFA
>
> - 3b & 4b are optional messages used if the BU includes a GFA or AFA
> address
> - 1 & 2 & 3 are mandatory messages that set a temporary tunnel between oFA
> and nFA
>
> The above modified version of the FA assisted has the following
> advantages:
> 1. Fast Handoff is isolated from Regional Registration or other
> hierarchical signaling.
> 2. The proactive establishment of the temporary tunnel between oFA and nFA
> provides Fast Handoff and helps to ensure zero packet loss during handoff
> 3. Retains the main advantages of the original FA assisted proposal:
>    - support for vanilla RFC2002 MIP clients,
>    - no additional signaling over the radio link.
>    - optional support for Regional Registration (or other hierarchical
> solutions)
>
> -Scott C. (and George T.)
>
>
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov  8 12:07:12 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01519
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Nov 2000 12:07:11 -0500 (EST)
Received: from standards (47.234.32.16:4977) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1F93@standards.nortelnetworks.com>; Wed, 8 Nov 2000 11:45:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 86908 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 11:45:04 -0500
Received: from RRMAIL01.RADIOROUTER_NT (63.103.94.23:3048) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB1F91@standards.nortelnetworks.com>; Wed, 8 Nov 2000
          11:45:04 -0500
Received: from jewels (sevellrealty.com [216.122.123.214]) by
          RRMAIL01.RADIOROUTER_NT with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id V8NKYPGG; Wed, 8 Nov 2000 11:44:48
          -0500
X-Sender: mscorson@popd.ix.netcom.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Approved-By:  "M. Scott Corson" <mscorson@IX.NETCOM.COM>
Message-ID:  <3.0.6.32.20001108114755.008ae1b0@popd.ix.netcom.com>
Date:         Wed, 8 Nov 2000 11:47:55 -0500
Reply-To: "M. Scott Corson" <mscorson@ix.netcom.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "M. Scott Corson" <mscorson@ix.netcom.com>
Subject:      Re: [MOBILE-IP] v4 fast handoff lack of interest?
X-To:         Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D243@il27exm03.cig.mot .com>

>        Raj and I are trying to discern whether the working group is a)
>uninterested in making a decision about the proposals (either one is fine)
>or b) uninterested in having a v4 fast handoff work item because it's not
>perceived as something that's going to be used.  It's hard for us to draw
>any conclusions on this without some comments.  Care to give us a sense
>about it?
>
>Thanks,
>Phil
>

Phil,

Just on time we have some comments.....and you thought that no one cared :-)

We feel that the FA assisted approach has a number of advantages over the
fast handoff approach. Most of the arguments, however, have been made
already in this list (see McCann's "[MOBILE-IP] Differences between the two
MIPv4 handoff approaches" for an example). The most important arguments
against Fast Handoff from our point of view is:
1. Increased signaling on the old link; which might be degrading.
2. Ability of the FA assisted approach to support vanilla RFC2002 MIP clients.

We do, however, feel that the FA assisted proposal can be improved.

Please consider the following modifications:
Lets use the basic idea of Source and Destination Trigger but also support
the following:
1. A temporary tunnel between old FA and new FA (whether GFA/AFA is used or
not)
2. The creation of this temporary tunnel to be based on BR/BU/BUAck
messages (see below)
3. Regional/Hierarchical mobile IP signaling to be optionally used in
parallel to the 1,2

In more particular:



                                                 +-----+
                                                 | GFA |
                                                 +-----+
                                                  ^  |
                                 2b. Regional Reg |  | 3b. Regional Reply
                                                  |  |
                                                  |  v
                      +-----+ 1. Binding Update  +-----+
                      |     | -----------------> |     |
                      | oFA | 2. Binding Ack     | nFA |
                      |     | <----------------- |     |
                      +-----+                    +-----+


                      +-----+    Movement        +-----+
                      | MN  | - - - - - - - - -> | MN  |
                      +-----+                    +-----+
       Figure 4 - "source trigger" hand-off optionally using either AFA or GFA

- 1 & 2 are mandatory messages that set a temporary (optionally
bi-directional) tunnel between oFA and nFA
- 2b & 3b are optional messages used if the BU includes a GFA or AFA address

                                                 +-----+
                                                 | GFA |
                                                 +-----+
                                                  ^  |
                                 3b. Regional Reg |  | 4b. Regional Reply
                                                  |  |
                              1. Binding Request  |  v
                      +-----+ <----------------  +-----+
                      |     | 2. Binding Update  |     |
                      | oFA | -----------------> | nFA |
                      |     | 3.  Binding Ack    |     |
                      +-----+ <----------------- +-----+


                      +-----+    Movement        +-----+
                      | MN  | - - - - - - - - -> | MN  |
                      +-----+                    +-----+
       Figure 5 - "target trigger" hand-off using either AFA or GFA

- 3b & 4b are optional messages used if the BU includes a GFA or AFA address
- 1 & 2 & 3 are mandatory messages that set a temporary tunnel between oFA
and nFA

The above modified version of the FA assisted has the following advantages:
1. Fast Handoff is isolated from Regional Registration or other
hierarchical signaling.
2. The proactive establishment of the temporary tunnel between oFA and nFA
provides Fast Handoff and helps to ensure zero packet loss during handoff
3. Retains the main advantages of the original FA assisted proposal:
   - support for vanilla RFC2002 MIP clients,
   - no additional signaling over the radio link.
   - optional support for Regional Registration (or other hierarchical
solutions)

-Scott C. (and George T.)


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov  8 12:12:16 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03269
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Nov 2000 12:12:16 -0500 (EST)
Received: from standards (47.234.32.16:4977) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2005@standards.nortelnetworks.com>; Wed, 8 Nov 2000 11:54:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 87061 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 11:54:09 -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBB2003@standards.nortelnetworks.com>;
          Wed, 8 Nov 2000 11:54:08 -0500
Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id KAA26152; Wed, 8 Nov 2000 10:10:10
          -0700 (MST)
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,v1.7) with ESMTP id
          JAA18738; Wed, 8 Nov 2000 09:10:09 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id JAA07780; Wed, 8 Nov 2000 09:10:08
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Patrice Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.973703249.10753.pcalhoun@nasnfs>
Date:         Wed, 8 Nov 2000 09:07:29 -0800
Reply-To: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] v4 fast handoff lack of interest?
X-To:         Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D256@il27exm03.cig.mot.com>

> > We do, however, feel that the FA assisted proposal can be improved.
> >
Speaking as one of the co-authors of the draft (but I presume that all authors
would agree with me), providing some command and/or improvements to the I-D
would be most appreciated. I will read your comments a little later and
provide my input.

Thanks,

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov  8 12:28:30 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08322
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Nov 2000 12:28:30 -0500 (EST)
Received: from standards (47.234.32.16:4977) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2060@standards.nortelnetworks.com>; Wed, 8 Nov 2000 12:10:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 87180 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 12:10:17 -0500
Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB205E@standards.nortelnetworks.com>; Wed, 8 Nov 2000 12:10:11
          -0500
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by
          motgate2.mot.com (motgate2 2.1) with ESMTP id KAA03852 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 8 Nov 2000 10:26:10
          -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116])
          by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA11872 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 8 Nov 2000 10:23:50
          -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2651.58) id
          <WMP3X5F0>; Wed, 8 Nov 2000 11:26:09 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain; charset="ISO-8859-1"
Approved-By:  Roberts Philip-qa3445 <Philip_Roberts-qa3445@EMAIL.MOT.COM>
Message-ID:  <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D257@il27exm03.cig.mot.com>
Date:         Wed, 8 Nov 2000 11:26:07 -0600
Reply-To: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home             ne
              tworkrenumbering
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I just want to emphasize one point in agreement with Charlie.  We need to
get this draft done.  It seems we're getting close.  Let's wrap it up.

Phil


> ----------
> From:         Charles E. Perkins
> Reply To:     Charles E. Perkins
> Sent:         Tuesday, November 7, 2000 1:33 AM
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home
> networkrenumbering
>
> Hello Mattias and Francis,
>
>
> Francis wrote in another thread:
>
> > The issue is what happens if the home link is renumbered when the MN is
> > stopped. In fact this depends on how the MN knows its home prefix(es):
> >  - very stupid implementations believe the MN is started at home then
> >    the home prefixes will be prefixes of the first attached link: no
> >    problem with renumbering.
> >  - stupid implementations use a static config in order to know home
> >    prefixes then if the config is too old the MN will not be able to
> >    find its home link (and a home agent).
> >  - someone suggested in the list to use a name which can be updated
> >    when the home prefix is renumbered (but not renamed :-). It is a
> >    fine idea out of the scope of the mobile IPv6 draft.
> > I think most implementations use the second way (static config)...
>
> One is left to wonder if there are any intelligent alternatives!
>
> I propose that the protocols and algorithms and procedures for getting
> an initial IPv6 home address allocated to a mobile node should all
> be declared out of scope, or otherwise we'll never get finished with
> the spec.
>
>
> >Mattias Pettersson wrote:
>
> > I've studied the thread above slightly and am a bit curious on
> > the effects of the new additions to the I-D below. It's still
> > the bootstrapping procedure which is of most interest; the
> > renumbering phase is a special case of the former. So: how does
> > the MN find it's home addresses and it's home agents?
>
> Likewise, I sincerely hope that these questions can be declared
> out of scope for the current draft.  On the other hand, I think it's
> a great discussion.
>
> > 1. The MN finds out its home prefix.
> > 2. MN performs DHAAD to find unicast address of an HA.
>
> That's a mighty big rabbit you just pulled out of that there hat ...
>
> > 3. MN sends RS to HA.
> > 4. HA sends RA with prefix list to MN.
> > 5. MN builds Home Addresses for all prefixes, by using address method
> > stated in prefix info.
> > 6. MN registers each Home Address.
> > 7. HA might help in address configuration (e.g. DAD)
> > 8. DNS should be updated, depending on address configuration method (it
> > should be done by the MN at this point, not earlier, IMO).
>
> What is the mobile node uses DHCP to update DNS?
>
> > Note that MN doesn't have a Home Address before step 5.
>
> Presumably, that would mean that the protocol you design would
> use a link-local address up until that point.
>
> > If home network renumbering occurs, while the MN is away from home, HA
> > normally takes care of informing the MN about new home prefixes. The MN
> > would run step 4-8 to synchronize with the renumbering.
>
> I'm not disagreeing with you, but my objective is to get the draft
> done, and making such dependencies for resynchronization purposes
> would be detrimental to that objective.
>
> > However, in the case when the MN is turned off for an extended period,
> > the MN won't be able to find it's HA again, and not even it's home
> prefix
> > to be able to run DHAAD. This is the same case as initial bootstrapping.
> > Step 1 has to be performed.
> >
> > As Francis said above, most implementations assume a manual
> > configuration of 1, i.e. the home prefix.  From there on you
> > can find out the home agents' anycast address and find a HA
> > to register with.  With Ken's contribution we now have a way
> > to find out all home addresses (BTW, what's been done in the
> > field of stateful autoconf of Home address and MIPv6?).
>
> I don't think a mobile node which is currently off-link can bootstrap
> from zero.  It has to at least have a security association with the
> home agent, and that has to depend on an IPv6 address, so you need to
> have an IPv6 address.  We can all try to design a better bootstrapping
> mechanism, which would clearly depend on finding new ways to identify
> a mobile node (other than using its home address).
>
> It took a year to standardize the Mobile IPv4 NAI extension, and there
> are still questions coming up on it.  My goal is to get a new Mobile IPv6
> Internet Draft done this week.  I hope we don't have to go down the
> path of specifying off-link bootstrapping from zero.
>
>
> > What we need at this stage is a new fall-back level, where the MN can
> > find it's home prefix independently of IP. So this is where AAA comes
> > in? MN would only need to know it's name (NAI?). Everything else can be
> > resolved from this.
>
> Agreed -- but next year, not this one.
>
>
> Regards,
> Charlie P.
>
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov  8 14:35:26 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10714
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Nov 2000 14:35:26 -0500 (EST)
Received: from standards (47.234.32.16:4997) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2234@standards.nortelnetworks.com>; Wed, 8 Nov 2000 14:16:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 87792 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 14:16:57 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB2232@standards.nortelnetworks.com>; Wed, 8 Nov 2000 14:16:57
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA08307;
          Wed, 8 Nov 2000 11:33:11 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA8JXAu31324; Wed, 8 Nov 2000 11:33:10
          -0800
X-Virus-Scanned:  Wed, 8 Nov 2000 11:33:10 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpddYcX7K; Wed, 08 Nov 2000
          11:32:55 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A09AA68.6443AB86@iprg.nokia.com>
Date:         Wed, 8 Nov 2000 11:32:56 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      [MOBILE-IP] Sending changed prefixes to the mobile node.
X-To:         Ken Powell <Ken.Powell@compaq.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Ken,

In your suggested modifications for section 9.7 of the
Mobile IPv6 draft, about "Renumbering the Home Subnet",
you suggested that notification should occur after the
prefix lifetime is reduced.  This is also specified in
draft revision 12.

It seems to me that the mobile node should also be
notified if the prefix lifetime increases.  The notification
does not have to be done urgently, of course.

Is there any reason why the notification should be done
only after reduction?

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov  8 15:34:04 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24906
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Nov 2000 15:34:03 -0500 (EST)
Received: from standards (47.234.32.16:4997) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB22CB@standards.nortelnetworks.com>; Wed, 8 Nov 2000 15:15:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 87984 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 15:15:55 -0500
Received: from ish7.ericsson.com.au (203.61.155.111:35928) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB22C9@standards.nortelnetworks.com>; Wed, 8 Nov 2000
          15:15:53 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id HAA04527 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 9 Nov 2000 07:28:49
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id HAA07107 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 9 Nov 2000 07:30:53
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <V42TYHGS>; Thu, 9 Nov 2000 07:31:07 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613DC7@eaubrnt018.epa.ericsson.se>
Date:         Thu, 9 Nov 2000 07:31:06 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] v4 fast handoff lack of interest?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

        Scott,

        Thanks for the interest. I have a comment on your
        criteria below.

        Hesham


> Just on time we have some comments.....and you thought that no one cared
> :-)
>
> We feel that the FA assisted approach has a number of advantages over the
> fast handoff approach. Most of the arguments, however, have been made
> already in this list (see McCann's "[MOBILE-IP] Differences between the
> two
> MIPv4 handoff approaches" for an example). The most important arguments
> against Fast Handoff from our point of view is:
> 1. Increased signaling on the old link; which might be degrading.
>
        => That's a system specific issue.

> 2. Ability of the FA assisted approach to support vanilla RFC2002 MIP
> clients.
>
        => Actually to say that proactive only supports RFC2002 vanilla
        MIP clients is a wrong statement. I think both proposals support
        RFC2002 clients. However, the Fast Handoffs model is closer
        to RFC2002 than the proactive model. Note I'm talking about
        the overall model of shared control between he MN and the network.
        But Both support the RFC2002 MIP clients.

        Regards,
        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov  8 18:00:21 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28548
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Nov 2000 18:00:21 -0500 (EST)
Received: from standards (47.234.32.16:1117) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB241B@standards.nortelnetworks.com>; Wed, 8 Nov 2000 17:39:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 88437 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 17:39:29 -0500
Received: from zcamail04.zca.compaq.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB2419@standards.nortelnetworks.com>; Wed, 8 Nov 2000 17:39:29
          -0500
Received: by zcamail04.zca.compaq.com (Postfix,
          from userid 12345) id A0CAB787; Wed,  8 Nov 2000 14:56:09 -0800 (PST)
Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net
          [16.103.129.53]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id
          4260C74C; Wed,  8 Nov 2000 14:56:09 -0800 (PST)
Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service
          (5.5.2650.21) id <WQXV1YB9>; Wed, 8 Nov 2000 17:55:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Powell, Ken" <Ken.Powell@COMPAQ.COM>
Message-ID:  <C99A689B0CB9D111AF3F0000F8062CCD08FB83BB@zkoexc2.zko.dec.com>
Date:         Wed, 8 Nov 2000 17:55:40 -0500
Reply-To: "Powell, Ken" <Ken.Powell@compaq.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Powell, Ken" <Ken.Powell@compaq.com>
Subject:      Re: [MOBILE-IP] Sending changed prefixes to the mobile node.
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Wednesday, November 08, 2000 2:33 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: [MOBILE-IP] Sending changed prefixes to the mobile node.
>
>
> Hello Ken,
>
> In your suggested modifications for section 9.7 of the
> Mobile IPv6 draft, about "Renumbering the Home Subnet",
> you suggested that notification should occur after the
> prefix lifetime is reduced.  This is also specified in
> draft revision 12.
>
> It seems to me that the mobile node should also be
> notified if the prefix lifetime increases.  The notification
> does not have to be done urgently, of course.

I agree.

>
> Is there any reason why the notification should be done
> only after reduction?

I was thinking that if the home agent periodically sent a
router advertisement with all prefixes every hour, then it
didn't really matter if the a special advertisement goes
out immediately just to tell a mobile node that a lifetime
changed from say 5 days to 2 weeks. Thinking about it again,
it would make a big difference if the lifetime changes from
5 minutes to 2 weeks, so better send the advertisement.
This probably won't happen very frequently, so it makes
sense to keep the logic simple. I wouldn't recommend adding
a special check for the initial lifetime being greater
than the max advertisement interval.

>
> Regards,
> Charlie P.
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 07:49:00 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10410
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 07:49:00 -0500 (EST)
Received: from standards (47.234.32.16:2571) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB27AD@standards.nortelnetworks.com>; Thu, 9 Nov 2000 7:30:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 89664 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 07:30:42 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB27AB@standards.nortelnetworks.com>; Thu, 9 Nov 2000 7:30:42
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id EAA11595;
          Thu, 9 Nov 2000 04:46:41 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA9CkeW27497; Thu, 9 Nov 2000 04:46:40
          -0800
X-Virus-Scanned:  Thu, 9 Nov 2000 04:46:40 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from Icharliep-1.iprg.nokia.com (205.226.22.18,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdSuZetT; Thu, 09 Nov 2000
          04:46:36 PST
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Charlie Perkins <charliep@IPRG.NOKIA.COM>
Message-ID:  <3A0A9C47.A9DD5107@iprg.nokia.com>
Date:         Thu, 9 Nov 2000 04:44:55 -0800
Reply-To: Charlie Perkins <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Charlie Perkins <charliep@IPRG.nokia.com>
Organization: Nokia
Subject:      [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-cc:         Richard Draves <richdr@microsoft.com>,
              Francis Dupont <Francis.Dupont@inria.fr>,
              Vijay Devarapalli <vijayd@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello,

I'm trying to follow up on some discussion a few days ago
about this point.  The last indication I received was that a
node receiving a packet with an ESP header should be
able to decrypt the payload using only the SPI and the
destination IPv6 address.  I had always thought that the
receiving node would want to use the mobile node's home
address to select the correct security association.  Recent
messages indicate that other implementations do not use
that information; then they presumably do not use the
IPv6 source address at all when identifying the correct
security association.

This is a crucial point, and a decision should be made ASAP.

There seem to be two additional relevant points:

- We should pick a placement for the Home Address option,
   and make it mandatory.  Doing so will simplify the implementation
   for all the billions of correspondent nodes of the future.  We want
   that implementation to be as simple as possible.  The two
   candidate placements are either after ESP, possibly in the
   same options header as the Binding Update, or else before
   the Fragment Header.

- Putting the information after ESP will make things substantially
   more complicated for possible firewall management.

Based on this evidence, I am leaning towards a mandatory placement
before the Fragment Header.  As soon as I can determine consensus
on this point, I am ready to issue a revised (and hopefully last)
Internet Draft for Mobile IPv6.

Thanks for your comments!

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 08:54:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03583
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 08:54:19 -0500 (EST)
Received: from standards (47.234.32.16:1191) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2829@standards.nortelnetworks.com>; Thu, 9 Nov 2000 8:33:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 89824 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 08:33:21 -0500
Received: from odin2.bull.net by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB2827@standards.nortelnetworks.com>; Thu, 9 Nov 2000 8:33:20
          -0500
Received: from ecbull20.frec.bull.fr (ecbull20.frec.bull.fr [129.183.4.3]) by
          odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA18954 for
          <MOBILE-IP@standards.nortelnetworks.com>; Thu, 9 Nov 2000 14:55:25
          +0100
Received: from isatis.frec.bull.fr (isatis.frec.bull.fr [129.183.144.1]) by
          ecbull20.frec.bull.fr (8.9.2/8.9.1) with ESMTP id OAA20524 for
          <MOBILE-IP@standards.nortelnetworks.com>; Thu, 9 Nov 2000 14:49:05
          +0100
Received: from bull.net (localhost [127.0.0.1]) by isatis.frec.bull.fr
          (AIX4.2/UCB 8.7/8.7) with ESMTP id OAA141208 for
          <MOBILE-IP@standards.nortelnetworks.com>; Thu, 9 Nov 2000 14:49:04
          +0100 (NFT)
X-Mailer: Mozilla 4.06 [en] (X11; I; AIX 4.2)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------5A454811332858495695F028"
Approved-By:  Aime.Le-Rouzic@BULL.NET
Message-ID:  <3A0AAB50.2CD2CBCD@bull.net>
Date:         Thu, 9 Nov 2000 14:49:04 +0100
Reply-To: AIme Le-Rouzic <Aime.Le-Rouzic@bull.net>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: AIme Le-Rouzic <Aime.Le-Rouzic@bull.net>
Organization: Bull
Subject:      [MOBILE-IP] [Fwd: [MOBILE-IP] Comment Please: Placement for Home
              Address
              option              header]
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------5A454811332858495695F028
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


--------------5A454811332858495695F028
Content-Type: message/rfc822
Content-Disposition: inline

Message-ID: <3A0AAB12.E33EC3F7@bull.net>
Date: Thu, 09 Nov 2000 14:48:02 +0100
From: AIme Le-Rouzic <Aime.Le-Rouzic@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.06 [en] (X11; I; AIX 4.2)
MIME-Version: 1.0
To: Charlie Perkins <charliep@IPRG.nokia.com>
CC: charliep@IPRG.nokia.com
Subject: Re: [MOBILE-IP] Comment Please: Placement for Home Address option              header
References: <3A0A9C47.A9DD5107@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

We are experimenting  MobileIPv6 plus IPSec on AIX with a firewall able
to process MobileIPv6 users.

Our conclusion is that the Home Address Option  MUST stay in front of
the ESP header to allow firewall to control those packets and so allow
users, securizing their datas with ESP, to keep their access when they
are outside as though they are at home by allowing the firewall
to do control on the home address.

By not allowing that to the users will kill MobileIPv6 .





Charlie Perkins wrote:
>
> Hello,
>
> I'm trying to follow up on some discussion a few days ago
> about this point.  The last indication I received was that a
> node receiving a packet with an ESP header should be
> able to decrypt the payload using only the SPI and the
> destination IPv6 address.  I had always thought that the
> receiving node would want to use the mobile node's home
> address to select the correct security association.  Recent
> messages indicate that other implementations do not use
> that information; then they presumably do not use the
> IPv6 source address at all when identifying the correct
> security association.
>
> This is a crucial point, and a decision should be made ASAP.
>
> There seem to be two additional relevant points:
>
> - We should pick a placement for the Home Address option,
>    and make it mandatory.  Doing so will simplify the implementation
>    for all the billions of correspondent nodes of the future.  We want
>    that implementation to be as simple as possible.  The two
>    candidate placements are either after ESP, possibly in the
>    same options header as the Binding Update, or else before
>    the Fragment Header.
>
> - Putting the information after ESP will make things substantially
>    more complicated for possible firewall management.
>
> Based on this evidence, I am leaning towards a mandatory placement
> before the Fragment Header.  As soon as I can determine consensus
> on this point, I am ready to issue a revised (and hopefully last)
> Internet Draft for Mobile IPv6.
>
> Thanks for your comments!
>
> Regards,
> Charlie P.

--------------5A454811332858495695F028--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 09:30:51 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16900
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 09:30:49 -0500 (EST)
Received: from standards (47.234.32.16:1191) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB28B4@standards.nortelnetworks.com>; Thu, 9 Nov 2000 9:12:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 90008 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 09:12:23 -0500
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB28B2@standards.nortelnetworks.com>; Thu, 9 Nov 2000 9:12:22
          -0500
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP
          id eA9ESct04805 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 9
          Nov 2000 15:28:38 +0100 (MET)
Received: from era.ericsson.se by era-t.ericsson.se
          (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id PAA18725; Thu, 9 Nov 2000 15:28:38
          +0100
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Mattias Pettersson <mattias.pettersson@ERA.ERICSSON.SE>
Message-ID:  <3A0AB48F.D2203A9A@era.ericsson.se>
Date:         Thu, 9 Nov 2000 15:28:31 +0100
Reply-To: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Radio Systems AB
Subject:      [MOBILE-IP] DAD
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi all,

I pointed this out in a separate mail, but inlined with a lot of other
text. Here is the separate comment on today's DAD:

/Mattias

-----

Charlie and others: I can't find anywhere in the I-D that the MN is
required to check its Home Address for DAD, other that during
renumbering. If the MN is given an address from start (hard coded or
statelessly created by combining home prefix and interface token), it
must set the D-flag in the initial BU to the HA. It must do this every
time the HA doesn't guard the address.

The current spec will only work if the MN at day 1 starts on the home
subnet.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 09:30:52 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16913
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 09:30:51 -0500 (EST)
Received: from standards (47.234.32.16:1191) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB28BC@standards.nortelnetworks.com>; Thu, 9 Nov 2000 9:12:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 90018 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 09:12:31 -0500
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBB28B9@standards.nortelnetworks.com>; Thu, 9 Nov 2000 9:12:30
          -0500
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP
          id eA9ESkZ16471; Thu, 9 Nov 2000 15:28:46 +0100 (MET)
Received: from era.ericsson.se by era-t.ericsson.se
          (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id PAA18728; Thu, 9 Nov 2000 15:28:46
          +0100
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
References: <C99A689B0CB9D111AF3F0000F8062CCD08FB83B7@zkoexc2.zko.dec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Mattias Pettersson <mattias.pettersson@ERA.ERICSSON.SE>
Message-ID:  <3A0AB497.8A59CB00@era.ericsson.se>
Date:         Thu, 9 Nov 2000 15:28:40 +0100
Reply-To: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Radio Systems AB
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home networkrenumbe
              ring
X-To:         "Powell, Ken" <Ken.Powell@compaq.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Ken,

"Powell, Ken" wrote:

> Mattias,
>
> I think you have a very important initialization concern,
> primarily because it impacts the way RS's and RA's are
> sent between the home agent and the mobile node. It boils
> down to a question of can we assume the mobile node will
> always have a home address before the first RS/RA exchange?
> I hope so, because if not, the technique for sending RS/RA
> is broken. Further details below (along with plenty of other
> stuff).
>

I would like the option to let the MN configure it's home address as if it
was at home, even if it is not at home.

There are two different uses of RS/RA:

1. HA sends RA to MN to synchronize MN with renumbering. An ack is needed.
BU from MN to HA in return has been chosen for this. Both RA and BU needs
AH. We could theoretically choose another ack method.

2. MN sends RS to HA to learn on home link autoconfiguration (prefixes,
address configuration method, etc). HA replies with RA. We don't need a BU
after this. RS doesn't necessarily need a AH, but the RA must have it. We
could secure it by other means than using the home address.

>
> > I'd like to open up for a simple procedure, see below.
>
> I had asked about a similar procedure before. I believe
> Charlie was thinking about adding it in an appendix as an
> FYI. That made sense to me given that the procedure simply
> showed how a mobile node could use existing protocol
> mechanisms to initialize itself. It didn't really add
> any protocol requirements. I also agree with Charlie
> that we should not block the current spec to sort
> out all details of initialization.
>

That's what I want.

>
> <snip>
>
> Following your proposed list of initialization steps:
>
> > 1. The MN finds out its home prefix.
>
> One possible option for this was to statically configure in
> the mobile node the fully qualified domain name of the home
> agent's anycast address. This would allow the mobile node to:
>
> 1a. Query DNS for the home agent's anycast address.
> 1b. Temporarily use the prefix from the home agent's
>     anycast address for the home subnet prefix.
> 1c. Use the temporary home subnet prefix and a globally
>     unique interface id to autoconfigure a temporary home
>     subnet address for the mobile node.
>
> I'm hoping for a better technique to be defined in the
> future possibly using AAA that covers IPsec requirements
> as well.
>

Ok. I accept this as one possible way.

>
> > 2. MN performs DHAAD to find unicast address of an HA.
> > 3. MN sends RS to HA.
> > 4. HA sends RA with prefix list to MN.
>
> Given the current method of how RS and RA are exchanged
> between the mobile node and home agent, you have to have
> a global scope home address for the mobile node by step 3.
> You also have to have a valid binding between the mobile
> node and the home agent for the home agent to return the
> RA. Therefore, it makes sense for the mobile node to
> send the BU option for its temporary address with the
> initial RS.
>

Yes, given the current method. But if I suggest a new way of automagically
configure the home address, exactly as it would have been done on the home
link, the current method has to be slightly modified. I think we introduce
more modularity/independence if MIPv6 can make use of existing address
allocation methods, rather than introducing a new, still not sorted out,
method that only MNs use.

>
> > 5. MN builds Home Addresses for all prefixes, by using
> >address method stated in prefix info.
> > 6. MN registers each Home Address.
> > 7. HA might help in address configuration (e.g. DAD)
> > 8. DNS should be updated, depending on address configuration
> > method (it should be done by the MN at this point, not
> > earlier, IMO).
> >
> > Ok. Let's agree on leaving the big issues out of scope.
>
> Would listing such steps in an appendix be OK with you?

Fine.

> > Home Prefix (needed to find Home Agents) conf alts:
> > 1A. Manual:
> >     - won't survive home network renum when MN is off.
> > 1B. Always start home or user interaction (button...):
> >     - same, plus need to start at home, a difficult demand
> > 1C. AAA:
> >     - will survive anything.
>
> I have no idea what AAA does for us on this. I wouldn't
> assume it could be used as an alternative to stateless
> address autoconfiguration or DHCPv6.
>

Here we are talking about finding out the home prefix, not the home
address.

Please see Hesham's comment in another mail.

>
> Would you add the following as another option?
>
>   1D. Store prefix in DNS.
>        - Must assume a prefix length.

Ok.

> >
> > Home Address conf alts:
>
> Why have two separate lists for home prefix and home address?
> It seems to me the technique for determining the home address is
> closely tied to the method for determining home prefix.

No. You need the home prefix to find a home agent that can tell you in an
RA how to configure your home address.

> > 2A. Manual:
> >     - not the best idea. MN can't check its Home Address
> >       for DAD.
>
> DAD must be used even with manual address configuration.

Charlie and others: I can't find anywhere in the I-D that the MN is
required to check its Home Address for DAD, other that during renumbering.
If the MN is given an address from start (hard coded or statelessly
created by combining home prefix and interface token), it must set the
D-flag in the initial BU to the HA. It must do this every time the HA
doesn't guard the address.

The current spec will only work if the MN at day 1 starts on the home
subnet.

> >     - What is the relationship between a manual address and
> >       the renumbered autoconfigured address?
> > 2B. Autoconf by RA from Home Link (either directly from Home
> >     Link or tunneled by HA):
> >     - MN will be configured just as if it was home.
> > 2C. AAA:
> >     - then addresses are configured and distributed by other
> >       means than IPv6 ND autoconf (state{ful,less})
> >     - if renumbering occurs MN must get new address though
> >        AAA rather than RA.
>
> Could AAA be defined to work with stateless address
> autoconfiguration or DHCPv6 instead of as an alternative?
> Perhaps AAA could somehow bootstrap these other mechanisms.
> I know nothing about AAA beyond the idea that it provides
> information necessary to establish a security association
> between the home agent and the mobile node.

>
> >
> > What I want is to open up the possibility for the MN to go
> > through step 2-5 without neither having a home address nor
> > having been at home before:
>
> I don't think we can do this without changing the way RS's and
> RA's are sent. I think this issue is very important to resolve
> now because a change later to the method for sending RS's and
> RA's won't be upward compatible.

Yes, I don't want to lock out such ideas in the draft. If we need to
finish this revision of the I-D urgently, we can go for this solution
right now. Later we have two options:
1. fix it in future revisions of MIPv6... rev 17 or so... ;)
2. put this in a draft that overrides MIPv6 in certain areas. Then we will
of course have backward compatibility problems.

[...]

> >
> > >  -  The Source Address in the packet's IPv6 header MUST be set
> > >     to the mobile node's primary care-of address.
> > >
> > >  -  The packet MUST be protected by IPsec [13, 11, 12] to guard
> > >     against malicious Router Solicitations.  The IPsec protection
> > >     MUST provide sender authentication, data integrity protection,
> > >     and replay protection, covering the Router Solicitation.
> > >
> > >  - The packet MUST include a Home Address destination option,
> > >    giving the mobile node's home address for its current
> > >    binding.
> > >
> > >  - The packet MUST include a Binding Update destination option
> > >    as described in section 10.6 if a current binding does not
> > >    yet exist. Otherwise, it MAY include a Binding Update
> > >    destination option.
> >
> > Here we have a problem. If the MN doesn't have a home address
> > it can't provide any at this point (step 3 above).
>
> Agreed. This is a problem for both the RS and RA. The way they
> are exchanged requires that the mobile node have at least one
> home address first. Some months back, I asked if it would be
> reasonable for the mobile node to generate a temporary address
> (very short lifetime) to get past this exchange. Such an
> address would only be allowed if it was based on a globally
> unique interface id.

I don't see why the exact look of the address would matter.

> > Is there a way we can leave this open for a lost MN with no
> > home address?
>
> The only way I could think of was to always tunnel the RA and
> RS per RFC 2473 instead of using the home address option
> and the routing header. I tried to think of ways to
> initialize using link-local addresses or the unspecified
> address for the mobile node, but doing so without a tunneled
> IPv6 header violated the base spec.
>

I think we can always tunnel ourselves away from problems... :)

> The problem with switching to RFC 2473 tunneling is that
> we would have to clearly define how to secure the message,
> how to associate a tunneled message to a specific binding,
> what to do if no binding exists, and how to attach a binding
> update/acknowledge option to a tunneled RS/RA.

I would try to avoid BUs/BAs now.

>
>
> It seemed much simpler and less disruptive to the current
> spec to let the mobile node generate a temporary address.

Ok, I see.

>
>
> > However, we must still secure the protocol, of course, but we
> > can do this
> > without a home address.
> >
> > Are the Home Address Option and Binding Update really needed,
> > unless the HA is
> > expecting an ack?
>
> Hmm, I hadn't thought of this. If I understand you correctly,
> your suggesting the mobile node send the RS directly from
> its care-of address to the home agent with no home address
> option? I suppose it could work, but I'm not comfortable
> with it. This implies to me that the home agent returns
> the RA back to the mobile node's care-of address with no
> routing header. The home agent would normally put the mobile
> node's home address in the routing header, but the mobile
> node doesn't have a home address configured yet. This
> solution feels to me like exchanging RS's and RA's over one
> interface (with the care-of address) to configure another
> interface (with the home address).

Correct! But the home address interface could under some circumstances be
regarded as lying on top of other more physical interfaces where the
care-of addresses are. Isn't this exactly what happens during tunneled RA
from HA to renumber the MN?

>
> Of the three options for handling RS's and RA's, my
> preference is:
>
>  1st: Keep the current mechanisms which require that the
>       mobile node somehow get an initial home prefix and
>       address before communication starts. Method to be
>       specified later.
>
>  2nd: Use RFC 2473 style tunneling.
>
>  last: Exchange RS's and RA's directly between a
>       the home agent and the mobile node's care-of
>       address to configure the mobile node's home
>       addresses.
>
> Ken

So, I'd like to refine my proposed procedure once again:

1. MN somehow knows it's home prefix (manual, name, AAA & NAI, ...)
2. MN sends RS to HA
  2a. MN has to find an HA first by DHAAD.
  2b. For DHAAD MN needs to send ICMP HAAD Request to anycast address
  2c. One HA replies with Home Agents list.
  2d. MN picks one HA and tunnels an RS to it.
        Outer src= care-of address
        Outer dst= HA's global address
        Inner src= whatever... CoA or LL maybe.
        Inner dst= ff02::x
        This packet doesn't need AH. I don't see this as a possible DoS
threat.
3. HA returns an RA. This message must not include a binding request (MN
is polling).
    This packet must be covered by AH. An SA has to be set up between MN's
CoA
    and the HA. How this is done is out of scope, but MN and HA have some
shared secret
    or can be verified by someone.
4. MN parses RA and configures all prefixes and addresses according to the

    method stated there.
  4a. If stateless is used: form Home address statelessly and let HA run
DAD for it.
  4b. If stateful is used: talk to DHCPv6 server to receive an address.
Currently,
        DHCPv6 is based on link- or site-local multicast. MN might have to
tunnel
        the request and reply via the HA.
  4c. If future methods are used: tunnel requests through home agent.
5. MN registers with HA by sending BUs for all Home Addresses. This time a
new
    SA is set up between MN and HA. HA checks DAD if needed.

Summary: we don't need a parallel address configuration method for mobile
nodes. A mobile node will be configured exactly as if it was at home.

/Mattias


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 09:58:49 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27179
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 09:58:49 -0500 (EST)
Received: from standards (47.234.32.16:1191) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB296E@standards.nortelnetworks.com>; Thu, 9 Nov 2000 9:40:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 90247 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 09:40:38 -0500
Received: from ztxmail03.ztx.compaq.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB296C@standards.nortelnetworks.com>; Thu, 9 Nov 2000 9:40:37
          -0500
Received: by ztxmail03.ztx.compaq.com (Postfix,
          from userid 12345) id 43058A60; Thu,  9 Nov 2000 08:56:54 -0600 (CST)
Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net
          [16.103.129.42]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id
          0403B7F5; Thu,  9 Nov 2000 08:56:53 -0600 (CST)
Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service
          (5.5.2652.78) id <WQVS5XH5>; Thu, 9 Nov 2000 09:56:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Powell, Ken" <Ken.Powell@COMPAQ.COM>
Message-ID:  <C99A689B0CB9D111AF3F0000F8062CCD08FB83BD@zkoexc2.zko.dec.com>
Date:         Thu, 9 Nov 2000 09:56:46 -0500
Reply-To: "Powell, Ken" <Ken.Powell@compaq.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Powell, Ken" <Ken.Powell@compaq.com>
Subject:      Re: [MOBILE-IP] DAD
X-To:         Mattias Pettersson <mattias.pettersson@era.ericsson.se>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Good point. I misunderstood your intent in
the previous message. I think such a statement
should be added.

> -----Original Message-----
> From: Mattias Pettersson [mailto:mattias.pettersson@era.ericsson.se]
> Sent: Thursday, November 09, 2000 9:29 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: [MOBILE-IP] DAD
>
>
> Hi all,
>
> I pointed this out in a separate mail, but inlined with a lot of other
> text. Here is the separate comment on today's DAD:
>
> /Mattias
>
> -----
>
> Charlie and others: I can't find anywhere in the I-D that the MN is
> required to check its Home Address for DAD, other that during
> renumbering. If the MN is given an address from start (hard coded or
> statelessly created by combining home prefix and interface token), it
> must set the D-flag in the initial BU to the HA. It must do this every
> time the HA doesn't guard the address.
>
> The current spec will only work if the MN at day 1 starts on the home
> subnet.
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 10:20:42 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07308
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 10:20:41 -0500 (EST)
Received: from standards (47.234.32.16:1191) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB29CC@standards.nortelnetworks.com>; Thu, 9 Nov 2000 10:02:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 90372 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 10:02:25 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB29CA@standards.nortelnetworks.com>; Thu, 9 Nov 2000 10:02:24
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA18704;
          Thu, 9 Nov 2000 07:18:41 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA9FIdu09932; Thu, 9 Nov 2000 07:18:39
          -0800
X-Virus-Scanned:  Thu, 9 Nov 2000 07:18:39 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpd8ANeOg; Thu, 09 Nov 2000
          07:18:35 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <3A0AB48F.D2203A9A@era.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A0AC04D.8BC4C8F6@iprg.nokia.com>
Date:         Thu, 9 Nov 2000 07:18:37 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] DAD
X-To:         Mattias Pettersson <mattias.pettersson@era.ericsson.se>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Matthias,

On page 22, the current specification says:

         ...      The mobile node SHOULD set the Duplicate Address
         Detection (D) bit based on any requirements for Duplicate
         Address Detection that would apply to the mobile node if it
         were at home [17, 27].

Why isn't this sufficient?

Regards,
Charlie P.



Mattias Pettersson wrote:
>
> Hi all,
>
> I pointed this out in a separate mail, but inlined with a lot of other
> text. Here is the separate comment on today's DAD:
>
> /Mattias
>
> -----
>
> Charlie and others: I can't find anywhere in the I-D that the MN is
> required to check its Home Address for DAD, other that during
> renumbering. If the MN is given an address from start (hard coded or
> statelessly created by combining home prefix and interface token), it
> must set the D-flag in the initial BU to the HA. It must do this every
> time the HA doesn't guard the address.
>
> The current spec will only work if the MN at day 1 starts on the home
> subnet.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 10:40:20 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14082
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 10:40:19 -0500 (EST)
Received: from standards (47.234.32.16:1191) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2A2B@standards.nortelnetworks.com>; Thu, 9 Nov 2000 10:22:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 90495 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 10:22:04 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB2A29@standards.nortelnetworks.com>; Thu, 9 Nov 2000 10:22:03
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA20148;
          Thu, 9 Nov 2000 07:38:20 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA9FcHW04797; Thu, 9 Nov 2000 07:38:17
          -0800
X-Virus-Scanned:  Thu, 9 Nov 2000 07:38:17 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpd5wqTK4; Thu, 09 Nov 2000
          07:38:13 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A0AC4E8.CDE13238@iprg.nokia.com>
Date:         Thu, 9 Nov 2000 07:38:16 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      [MOBILE-IP] Binding Cache entries per IPv6 address at
              Correspondent Node
X-To:         Mattias Pettersson <mattias.pettersson@era.ericsson.se>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Mattias,

Some time ago, you sent the following e-mail:

> Hi,
>
> during testing at Connectathon 2000 I stumbled into the following
> problem:
>
> A CN/HA with more than one interface address may get independent BUs
> sent to it. The mobile node will consider them as different nodes and
> keep one BUL entry for each of them. Especially, it will use independent
> sets of sequence numbers, which in turn will cause the receiving CN/HA
> to get very confused (and not accept the BUs).
>
> This can happen to any host/router that has multiple interface addresses
> of the same scope as the home address, not only nodes with multiple
> interfaces.
>
> My suggestion is to keep a Binding Cache on a CN/HA for every interface
> address that's assigned, and to clear this out in the draft under
> "Conceptual structs". Currently you can read both do and don't out of
> the spec. It will be more complex, but it is the logical way to do it.

Here is what I have added to the Internet Draft, as you suggested:



 Binding Cache

         A cache, maintained by each IPv6 node, of bindings for other
         nodes.  A separate Binding Cache SHOULD be maintained by each
         IPv6 node for each of its IPv6 addresses.

                      ...........

                 The contents of all of a node's Binding Cache entries,
         for each of its IPv6 addresses, must be cleared when the node
         reboots.



In addition, I have changed several places where it seems to
read better to allow multiple Binding Caches (one per IPv6 address).

Does this fix the problem, without introducing any new problems?

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 12:29:22 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24167
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 12:29:22 -0500 (EST)
Received: from standards (47.234.32.16:1700) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2B8E@standards.nortelnetworks.com>; Thu, 9 Nov 2000 12:10:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 90972 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 12:10:39 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB2B8C@standards.nortelnetworks.com>; Thu, 9 Nov 2000 12:10:39
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA00224
          for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 9 Nov 2000
          09:26:50 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA9HQlH32231 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 9 Nov 2000 09:26:47
          -0800
X-Virus-Scanned:  Thu, 9 Nov 2000 09:26:47 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdCnhxGU; Thu, 09 Nov 2000
          09:26:30 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A0ADE49.DA37A9AA@iprg.nokia.com>
Date:         Thu, 9 Nov 2000 09:26:33 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      [MOBILE-IP] Swapping care-of address and home address
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello folks,

Here's another conundrum that has to be settled.

Problem:
        How is AH calculated when care-of address is
        initially present in the IPv6 header, and the
        Home Address option is present.

Proposal:
        Exchange the care-of address in the IPv6 header
        with the home address in the Home Address option.
        Then, when AH is calculated on the receiving end,
        the care-of address will be present in the data
        field of the Home Address option, and the home
        address will be present in the IPv6 header.

Also:
        When the Binding Update is present, a Home Address
        option is mandatory.  The above proposal means that
        when the inbound Binding Update processing occurs,
        the care-of address has to be retrieved from the
        Home Address option instead of the IPv6 header.


Thinking about the alternatives, while required, is enough
to give one a migraine headache.  For those who dare go on,
please don't say I didn't warn you.

Alternative 1: Keep both in place
        This means that all subsequent processing has to be
        special cased depending on whether or not a Home
        Address option has been processed.  The code I have
        seen (e.g., protocol-switch based code) has a hard
        time dealing with this.

Alternative 2: Copy the home address into the IPv6 header,
        and do not copy the care-of address into the Home
        Address option.  This doesn't simplify anything, and
        just makes it harder to retrieve the care-of address.


I'm not exactly sure whether there has already been agreement
on this or not.  I know there's been plenty of discussion.
There seems to be three main camps:
        - Leave the fields where they are, and
        - Exchange them
        - Do almost anything reasonable, but pick something
          definite and make it mandatory.

I hope this qualifies to satisfy those in the last two camps,
at least.  And, I think that there is general agreement that
the current wording of the draft has to be changed somehow
to make it clear which alternative is being specified.

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 13:16:41 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10857
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 13:16:40 -0500 (EST)
Received: from standards (47.234.32.16:1700) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2C44@standards.nortelnetworks.com>; Thu, 9 Nov 2000 12:58:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 91221 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 12:58:23 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB2C42@standards.nortelnetworks.com>; Thu, 9 Nov 2000 12:58:22
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA04898
          for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 9 Nov 2000
          10:14:39 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA9IEaG15179 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 9 Nov 2000 10:14:36
          -0800
X-Virus-Scanned:  Thu, 9 Nov 2000 10:14:36 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdFpbame; Thu, 09 Nov 2000
          10:14:32 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A0AE98B.46A6DD3E@iprg.nokia.com>
Date:         Thu, 9 Nov 2000 10:14:35 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      [MOBILE-IP] Placement for Binding Update and Home Address options
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello again,

Here's another puzzler -- actually, two.

Most discussions have the Binding Update appearing after
the IPsec headers.  This is presumably to offer some
protection against monitoring how often the mobile node
has to send Binding Updates to its correspondent nodes
and home agent(s), without having to incur the expense
of wrapping the whole packet in tunnel mode encryption.

However, the current specification allows for the Binding
Update to be inserted in the same Option header as the
Home Address destination option.  The advantage in doing
that is to save space.  The disadvantage is that then there
are always two legally specified places for the Binding
Update to appear, making processing more complicated.

The second question involves where the first Destination
Options header should be placed.  After quite a bit of
discussion and thought, I have come to the conclusion
that it should be located _after_ the Routing Header
but _before_ the Fragment Header.  The reasons are that
intermediate routers SHOULD NOT process the Home Address
destination option, but firewall SHOULD see the same
home address for all fragments.

I think I have that right, but I'm mainly offering it for
discussion.

Bottom line _proposal_:

Mandatory placements:
        - Home Address option between Routing and Fragment Headers
        - Binding Update after ESP.

Comments?

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 13:27:24 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14589
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 13:27:22 -0500 (EST)
Received: from standards (47.234.32.16:1700) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2CA5@standards.nortelnetworks.com>; Thu, 9 Nov 2000 13:08:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 91352 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 13:08:49 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB2CA3@standards.nortelnetworks.com>; Thu, 9 Nov 2000 13:08:49
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA06002;
          Thu, 9 Nov 2000 10:25:06 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA9IP3800559; Thu, 9 Nov 2000 10:25:03
          -0800
X-Virus-Scanned:  Thu, 9 Nov 2000 10:25:03 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from vijayd.iprg.nokia.com (205.226.2.94,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdOsQwPf; Thu, 09 Nov 2000
          10:24:57 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <3A0ADE49.DA37A9AA@iprg.nokia.com>
Content-Type: multipart/mixed; boundary="------------4F21ECD8BDF0DAB71DF0A641"
Approved-By:  vijayd@IPRG.NOKIA.COM
Message-ID:  <3A0AEBFC.E4335E0F@iprg.nokia.com>
Date:         Thu, 9 Nov 2000 10:25:00 -0800
Reply-To: Vijay Devarapalli <vijayd@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Vijay Devarapalli <vijayd@IPRG.nokia.com>
Subject:      Re: [MOBILE-IP] Swapping care-of address and home address
X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------4F21ECD8BDF0DAB71DF0A641
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


> Alternative 2: Copy the home address into the IPv6 header,
>         and do not copy the care-of address into the Home
>         Address option.  This doesn't simplify anything, and
>         just makes it harder to retrieve the care-of address.

The CoA is not protected by AH in this case.

Vijay
--------------4F21ECD8BDF0DAB71DF0A641
Content-Type: text/x-vcard; charset=us-ascii;
 name="vijayd.vcf"
Content-Description: Card for Vijay Devarapalli
Content-Disposition: attachment;
 filename="vijayd.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Devarapalli;Vijay
tel;cell:(650) 302 8629
tel;work:(650) 625 2320
x-mozilla-html:FALSE
org:Nokia Research Center
version:2.1
email;internet:vijayd@iprg.nokia.com
title:Research Enginner
adr;quoted-printable:;;313 Fairchild Drive=0D=0A;Mountain View;CA;95051;USA
x-mozilla-cpt:;-12992
fn:Vijay Devarapalli
end:vcard

--------------4F21ECD8BDF0DAB71DF0A641--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 13:44:06 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20213
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 13:44:05 -0500 (EST)
Received: from standards (47.234.32.16:1700) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2D0D@standards.nortelnetworks.com>; Thu, 9 Nov 2000 13:25:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 91492 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 13:25:42 -0500
Received: from ztxmail03.ztx.compaq.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB2D0B@standards.nortelnetworks.com>; Thu, 9 Nov 2000 13:25:41
          -0500
Received: by ztxmail03.ztx.compaq.com (Postfix,
          from userid 12345) id E27E410FA; Thu,  9 Nov 2000 12:41:58 -0600 (CST)
Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net
          [16.103.129.42]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id
          43ECD13B1; Thu,  9 Nov 2000 12:41:58 -0600 (CST)
Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service
          (5.5.2652.78) id <WQVS6K9Q>; Thu, 9 Nov 2000 13:41:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Powell, Ken" <Ken.Powell@COMPAQ.COM>
Message-ID:  <C99A689B0CB9D111AF3F0000F8062CCD08FB83BE@zkoexc2.zko.dec.com>
Date:         Thu, 9 Nov 2000 13:41:50 -0500
Reply-To: "Powell, Ken" <Ken.Powell@compaq.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Powell, Ken" <Ken.Powell@compaq.com>
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home networkrenumbe
              ring
X-To:         Mattias Pettersson <mattias.pettersson@era.ericsson.se>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Mattias,

I fear we are not resolving this very fast. The only
clean solution I see that would satisfy both of us
is to use tunnels for RS/RA, but that means plenty
of work real fast. I don't want to start a concrete
proposal unless others think its worth the effort.

Detailed comments below.

> -----Original Message-----
> From: Mattias Pettersson [mailto:mattias.pettersson@era.ericsson.se]
> Sent: Thursday, November 09, 2000 9:29 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] How Mobile IPv6 should handle home
> networkrenumbe ring
>
>
> Hi Ken,
>
> "Powell, Ken" wrote:
>
> > Mattias,
> >
> > I think you have a very important initialization concern,
> > primarily because it impacts the way RS's and RA's are
> > sent between the home agent and the mobile node. It boils
> > down to a question of can we assume the mobile node will
> > always have a home address before the first RS/RA exchange?
> > I hope so, because if not, the technique for sending RS/RA
> > is broken. Further details below (along with plenty of other
> > stuff).
> >
>
> I would like the option to let the MN configure it's home
> address as if it was at home, even if it is not at home.

Yes, I was shooting for that goal too.

>
> There are two different uses of RS/RA:
>
> 1. HA sends RA to MN to synchronize MN with renumbering. An
> ack is needed. BU from MN to HA in return has been chosen for
> this. Both RA and BU needs AH. We could theoretically choose
> another ack method.
>
> 2. MN sends RS to HA to learn on home link autoconfiguration
> (prefixes, address configuration method, etc). HA replies
> with RA. We don't need a BU after this. RS doesn't necessarily
> need a AH, but the RA must have it. We could secure it by other
> means than using the home address.

I think unless we find another ACK method, I would prefer to
keep the BU at the end of use 2. This is a tradeoff between
simplicity and efficiency (i.e., "always ACK" vs "ACK except
under certain conditions").

>
> >
> > Following your proposed list of initialization steps:
> >
> > > 1. The MN finds out its home prefix.
> >
> > One possible option for this was to statically configure in
> > the mobile node the fully qualified domain name of the home
> > agent's anycast address. This would allow the mobile node to:
> >
> > 1a. Query DNS for the home agent's anycast address.
> > 1b. Temporarily use the prefix from the home agent's
> >     anycast address for the home subnet prefix.
> > 1c. Use the temporary home subnet prefix and a globally
> >     unique interface id to autoconfigure a temporary home
> >     subnet address for the mobile node.
> >
> > I'm hoping for a better technique to be defined in the
> > future possibly using AAA that covers IPsec requirements
> > as well.
> >
>
> Ok. I accept this as one possible way.
>
> >
> > > 2. MN performs DHAAD to find unicast address of an HA.
> > > 3. MN sends RS to HA.
> > > 4. HA sends RA with prefix list to MN.
> >
> > Given the current method of how RS and RA are exchanged
> > between the mobile node and home agent, you have to have
> > a global scope home address for the mobile node by step 3.
> > You also have to have a valid binding between the mobile
> > node and the home agent for the home agent to return the
> > RA. Therefore, it makes sense for the mobile node to
> > send the BU option for its temporary address with the
> > initial RS.
>
> Yes, given the current method. But if I suggest a new way
> of automagically configure the home address, exactly as it
> would have been done on the home link, the current method
> has to be slightly modified. I think we introduce more
> modularity/independence if MIPv6 can make use of existing
> address allocation methods, rather than introducing a new,
> still not sorted out, method that only MNs use.

OK, I think we have the same objectives here.

> >
> > > 5. MN builds Home Addresses for all prefixes, by using
> > >address method stated in prefix info.
> > > 6. MN registers each Home Address.
> > > 7. HA might help in address configuration (e.g. DAD)
> > > 8. DNS should be updated, depending on address configuration
> > > method (it should be done by the MN at this point, not
> > > earlier, IMO).
> > >
> > > Ok. Let's agree on leaving the big issues out of scope.
> >
> > Would listing such steps in an appendix be OK with you?
>
> Fine.
>
> > > Home Prefix (needed to find Home Agents) conf alts:
> > > 1A. Manual:
> > >     - won't survive home network renum when MN is off.
> > > 1B. Always start home or user interaction (button...):
> > >     - same, plus need to start at home, a difficult demand
> > > 1C. AAA:
> > >     - will survive anything.
> >
> > I have no idea what AAA does for us on this. I wouldn't
> > assume it could be used as an alternative to stateless
> > address autoconfiguration or DHCPv6.
> >
>
> Here we are talking about finding out the home prefix, not
> the home address.
>
> Please see Hesham's comment in another mail.

Is the real goal to find the home agents, not necessarily
the home prefixes? Perhaps thats what confused me. I
consider a mobile would want to get most of its home
prefix information, complete with lifetimes and flags,
from stateless or statefull address autoconfiguration
later on.

>
> >
> > Would you add the following as another option?
> >
> >   1D. Store prefix in DNS.
> >        - Must assume a prefix length.
>
> Ok.
>
> > >
> > > Home Address conf alts:
> >
> > Why have two separate lists for home prefix and home address?
> > It seems to me the technique for determining the home address is
> > closely tied to the method for determining home prefix.
>
> No. You need the home prefix to find a home agent that can
> tell you in an RA how to configure your home address.

I think you only need a single home agent anycast address.
The address can be derived from the prefix if you have one,
but in many cases, it could be easier to get the anycast
address directly.

>
> > > 2A. Manual:
> > >     - not the best idea. MN can't check its Home Address
> > >       for DAD.
> >
> > DAD must be used even with manual address configuration.
>
> Charlie and others: I can't find anywhere in the I-D that the MN
> is required to check its Home Address for DAD, other that during
> renumbering. If the MN is given an address from start (hard coded
> or statelessly created by combining home prefix and interface
> token), it must set the D-flag in the initial BU to the HA. It
> must do this every time the HA doesn't guard the address.

Saw your other message on this, good catch.

>
> The current spec will only work if the MN at day 1 starts on the home
> subnet.
>
> > >     - What is the relationship between a manual address and
> > >       the renumbered autoconfigured address?
> > > 2B. Autoconf by RA from Home Link (either directly from Home
> > >     Link or tunneled by HA):
> > >     - MN will be configured just as if it was home.
> > > 2C. AAA:
> > >     - then addresses are configured and distributed by other
> > >       means than IPv6 ND autoconf (state{ful,less})
> > >     - if renumbering occurs MN must get new address though
> > >        AAA rather than RA.
> >
> > Could AAA be defined to work with stateless address
> > autoconfiguration or DHCPv6 instead of as an alternative?
> > Perhaps AAA could somehow bootstrap these other mechanisms.
> > I know nothing about AAA beyond the idea that it provides
> > information necessary to establish a security association
> > between the home agent and the mobile node.
>
> >
> > >
> > > What I want is to open up the possibility for the MN to go
> > > through step 2-5 without neither having a home address nor
> > > having been at home before:
> >
> > I don't think we can do this without changing the way RS's and
> > RA's are sent. I think this issue is very important to resolve
> > now because a change later to the method for sending RS's and
> > RA's won't be upward compatible.
>
> Yes, I don't want to lock out such ideas in the draft. If we need to
> finish this revision of the I-D urgently, we can go for this solution
> right now. Later we have two options:
> 1. fix it in future revisions of MIPv6... rev 17 or so... ;)
> 2. put this in a draft that overrides MIPv6 in certain areas.
> Then we will of course have backward compatibility problems.
>
> [...]
>
> > >
> > > >  -  The Source Address in the packet's IPv6 header MUST be set
> > > >     to the mobile node's primary care-of address.
> > > >
> > > >  -  The packet MUST be protected by IPsec [13, 11, 12] to guard
> > > >     against malicious Router Solicitations.  The IPsec
> protection
> > > >     MUST provide sender authentication, data integrity
> protection,
> > > >     and replay protection, covering the Router Solicitation.
> > > >
> > > >  - The packet MUST include a Home Address destination option,
> > > >    giving the mobile node's home address for its current
> > > >    binding.
> > > >
> > > >  - The packet MUST include a Binding Update destination option
> > > >    as described in section 10.6 if a current binding does not
> > > >    yet exist. Otherwise, it MAY include a Binding Update
> > > >    destination option.
> > >
> > > Here we have a problem. If the MN doesn't have a home address
> > > it can't provide any at this point (step 3 above).
> >
> > Agreed. This is a problem for both the RS and RA. The way they
> > are exchanged requires that the mobile node have at least one
> > home address first. Some months back, I asked if it would be
> > reasonable for the mobile node to generate a temporary address
> > (very short lifetime) to get past this exchange. Such an
> > address would only be allowed if it was based on a globally
> > unique interface id.
>
> I don't see why the exact look of the address would matter.

The global interface id restriction was based on the idea that
the mobile node was generating and using the interface id from
local information only without running DAD first. The real
objective was to to ensure there was near zero chance of a
duplicate address with another node. It doesn't really matter
how this objective is met. This just seemed a simple way to
do it.

>
> > > Is there a way we can leave this open for a lost MN with no
> > > home address?
> >
> > The only way I could think of was to always tunnel the RA and
> > RS per RFC 2473 instead of using the home address option
> > and the routing header. I tried to think of ways to
> > initialize using link-local addresses or the unspecified
> > address for the mobile node, but doing so without a tunneled
> > IPv6 header violated the base spec.
> >
>
> I think we can always tunnel ourselves away from problems... :)

Or into more more problems ;)

>
> > The problem with switching to RFC 2473 tunneling is that
> > we would have to clearly define how to secure the message,
> > how to associate a tunneled message to a specific binding,
> > what to do if no binding exists, and how to attach a binding
> > update/acknowledge option to a tunneled RS/RA.
>
> I would try to avoid BUs/BAs now.

OK.

>
> >
> >
> > It seemed much simpler and less disruptive to the current
> > spec to let the mobile node generate a temporary address.
>
> Ok, I see.
>
> >
> >
> > > However, we must still secure the protocol, of course, but we
> > > can do this
> > > without a home address.
> > >
> > > Are the Home Address Option and Binding Update really needed,
> > > unless the HA is
> > > expecting an ack?
> >
> > Hmm, I hadn't thought of this. If I understand you correctly,
> > your suggesting the mobile node send the RS directly from
> > its care-of address to the home agent with no home address
> > option? I suppose it could work, but I'm not comfortable
> > with it. This implies to me that the home agent returns
> > the RA back to the mobile node's care-of address with no
> > routing header. The home agent would normally put the mobile
> > node's home address in the routing header, but the mobile
> > node doesn't have a home address configured yet. This
> > solution feels to me like exchanging RS's and RA's over one
> > interface (with the care-of address) to configure another
> > interface (with the home address).
>
> Correct! But the home address interface could under some
> circumstances be
> regarded as lying on top of other more physical interfaces where the
> care-of addresses are. Isn't this exactly what happens during
> tunneled RA
> from HA to renumber the MN?

Yes, but the existance of the tunnel header is an explicit
signal that the intended destination is the home network
pseudo interface insteaded of the care-of network
physical interface. The current use of routing header
and home address option do the same thing. I think we
need some form of explicit marker that indicates which
interface the RS/RA apply to.

>
> >
> > Of the three options for handling RS's and RA's, my
> > preference is:
> >
> >  1st: Keep the current mechanisms which require that the
> >       mobile node somehow get an initial home prefix and
> >       address before communication starts. Method to be
> >       specified later.
> >
> >  2nd: Use RFC 2473 style tunneling.
> >
> >  last: Exchange RS's and RA's directly between a
> >       the home agent and the mobile node's care-of
> >       address to configure the mobile node's home
> >       addresses.
> >
> > Ken
>
> So, I'd like to refine my proposed procedure once again:
>
> 1. MN somehow knows it's home prefix (manual, name, AAA & NAI, ...)

Could you change this to "knows its home agent anycast address"?

> 2. MN sends RS to HA
>   2a. MN has to find an HA first by DHAAD.
>   2b. For DHAAD MN needs to send ICMP HAAD Request to anycast address
>   2c. One HA replies with Home Agents list.
>   2d. MN picks one HA and tunnels an RS to it.

Could you give DHAAD procedure and home agent selection as
step two, then have separate step 3 for "MS sends RS..."?

>         Outer src= care-of address
>         Outer dst= HA's global address
>         Inner src= whatever... CoA or LL maybe.

Suggest using the "unspecified address" for the Inner src,
same as if the node were on-link.

>         Inner dst= ff02::x
>         This packet doesn't need AH. I don't see this as a
>         possible DoS threat.
> 3. HA returns an RA. This message must not include a binding
>     request (MN is polling).
>     This packet must be covered by AH. An SA has to be set up
>     between MN's CoA and the HA. How this is done is out of
>     scope, but MN and HA have some shared secret
>     or can be verified by someone.

How does the RA get returned? I think this needs to specify
using RFC 2473 style tunnel encapsulation instead of a routing
header. The mobile node doesn't have a global home address yet.
Would the following addresses make sense?

          Outer src= HA's global address
          Outer dst= care-of address
          Outer src= HA's home subnet link-local address
          Inner dst= all-nodes multicast address

> 4. MN parses RA and configures all prefixes and addresses
>     according to the method stated there.
>   4a. If stateless is used: form Home address statelessly and
>       let HA run DAD for it.
>   4b. If stateful is used: talk to DHCPv6 server to receive
>       an address. Currently, DHCPv6 is based on link- or
>       site-local multicast. MN might have to tunnel the request
>       and reply via the HA.

I don't think we should assume anything about how statefull
configuration is performed. How about say:

     4b. If the the M or O flags are set in the router
         advertisement, follow the statefull (DHCPv6)
         configuration procedures.

>   4c. If future methods are used: tunnel requests through home agent.

I don't see any reason to restrict future configuration methods
to always working through the home agent. I'm assuming your
describing requests of some as yet undefined protocol.

> 5. MN registers with HA by sending BUs for all Home Addresses.
>    This time a new SA is set up between MN and HA. HA checks DAD
>    if needed.
>
> Summary: we don't need a parallel address configuration
> method for mobile nodes. A mobile node will be configured
> exactly as if it was at home.

Looks like we are headed for parallel ways to send RA/RS
to avoid a parallel home address configuration method.
I'm not at all happy with doing that. I would rather see
us adopt a single consistent method for exchanging RS/RA.
If we have to change how RS/RA are sent, lets do it the
right way now.

Ken


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 13:56:50 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24661
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 13:56:50 -0500 (EST)
Received: from standards (47.234.32.16:1700) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2D73@standards.nortelnetworks.com>; Thu, 9 Nov 2000 13:38:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 91630 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 13:38:42 -0500
Received: from zcamail04.zca.compaq.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB2D71@standards.nortelnetworks.com>; Thu, 9 Nov 2000 13:38:41
          -0500
Received: by zcamail04.zca.compaq.com (Postfix,
          from userid 12345) id CAFDE56F; Thu,  9 Nov 2000 10:55:24 -0800 (PST)
Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net
          [16.103.129.53]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id
          62CD846B; Thu,  9 Nov 2000 10:55:24 -0800 (PST)
Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service
          (5.5.2650.21) id <WQXVG510>; Thu, 9 Nov 2000 13:54:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Powell, Ken" <Ken.Powell@COMPAQ.COM>
Message-ID:  <C99A689B0CB9D111AF3F0000F8062CCD08FB83BF@zkoexc2.zko.dec.com>
Date:         Thu, 9 Nov 2000 13:54:51 -0500
Reply-To: "Powell, Ken" <Ken.Powell@compaq.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Powell, Ken" <Ken.Powell@compaq.com>
Subject:      Re: [MOBILE-IP] DAD
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Charlie,

I think the problem is that the home agent will only
defend against a duplicate address when there is a binding
with the mobile node. This is something that the base specs
are not concerned with. Therefore, it might make sense
to add a statement like:

  The home agent will only defend against a duplicate
  address when there is a binding with the mobile node.
  Therefore, the mobile node MUST treat creation of a
  new binding with the home agent using an existing home
  address the same as creation of a new home address.

Ken

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Thursday, November 09, 2000 10:19 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] DAD
>
>
> Hello Matthias,
>
> On page 22, the current specification says:
>
>          ...      The mobile node SHOULD set the Duplicate Address
>          Detection (D) bit based on any requirements for Duplicate
>          Address Detection that would apply to the mobile node if it
>          were at home [17, 27].
>
> Why isn't this sufficient?
>
> Regards,
> Charlie P.
>
>
>
> Mattias Pettersson wrote:
> >
> > Hi all,
> >
> > I pointed this out in a separate mail, but inlined with a
> lot of other
> > text. Here is the separate comment on today's DAD:
> >
> > /Mattias
> >
> > -----
> >
> > Charlie and others: I can't find anywhere in the I-D that the MN is
> > required to check its Home Address for DAD, other that during
> > renumbering. If the MN is given an address from start (hard coded or
> > statelessly created by combining home prefix and interface
> token), it
> > must set the D-flag in the initial BU to the HA. It must do
> this every
> > time the HA doesn't guard the address.
> >
> > The current spec will only work if the MN at day 1 starts
> on the home
> > subnet.
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 14:26:52 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03217
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 14:26:52 -0500 (EST)
Received: from standards (47.234.32.16:1700) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2DF1@standards.nortelnetworks.com>; Thu, 9 Nov 2000 14:04:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 91795 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 14:04:06 -0500
Received: from ztxmail03.ztx.compaq.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB2DEF@standards.nortelnetworks.com>; Thu, 9 Nov 2000 14:04:05
          -0500
Received: by ztxmail03.ztx.compaq.com (Postfix,
          from userid 12345) id 1BF7510B0; Thu,  9 Nov 2000 13:20:23 -0600 (CST)
Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net
          [16.103.129.42]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id
          D63AF635; Thu,  9 Nov 2000 13:20:22 -0600 (CST)
Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service
          (5.5.2652.78) id <WQVS6N8Y>; Thu, 9 Nov 2000 14:20:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Powell, Ken" <Ken.Powell@COMPAQ.COM>
Message-ID:  <C99A689B0CB9D111AF3F0000F8062CCD08FB83C0@zkoexc2.zko.dec.com>
Date:         Thu, 9 Nov 2000 14:20:19 -0500
Reply-To: "Powell, Ken" <Ken.Powell@compaq.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Powell, Ken" <Ken.Powell@compaq.com>
Subject:      Re: [MOBILE-IP] Binding Cache entries per IPv6 address at Corresp
              ondent Node
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I'm not sure how the clause "for each of its IPv6 addresses"
applies when the prefix length is non-zero. In this case, a
single binding covers multiple addresses.

>
>  Binding Cache
>
>          A cache, maintained by each IPv6 node, of bindings for other
>          nodes.  A separate Binding Cache SHOULD be maintained by each
>          IPv6 node for each of its IPv6 addresses.
>
>                       ...........
>
>                  The contents of all of a node's Binding
> Cache entries,
>          for each of its IPv6 addresses, must be cleared when the node
>          reboots.
>
>
>
> In addition, I have changed several places where it seems to
> read better to allow multiple Binding Caches (one per IPv6 address).
>
> Does this fix the problem, without introducing any new problems?
>
> Regards,
> Charlie P.
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 16:40:21 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19409
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 16:40:21 -0500 (EST)
Received: from standards (47.234.32.16:2571) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2F7E@standards.nortelnetworks.com>; Thu, 9 Nov 2000 16:21:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 92335 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 16:21:38 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB2F7B@standards.nortelnetworks.com>; Thu, 9 Nov 2000 16:21:38
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA25567;
          Thu, 9 Nov 2000 13:37:55 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA9Lbqm19879; Thu, 9 Nov 2000 13:37:52
          -0800
X-Virus-Scanned:  Thu, 9 Nov 2000 13:37:52 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdR6ZlLm; Thu, 09 Nov 2000
          13:37:45 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A0B192A.472756C1@iprg.nokia.com>
Date:         Thu, 9 Nov 2000 13:37:46 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      [MOBILE-IP] Appendix
X-To:         Mattias Pettersson <mattias.pettersson@era.ericsson.se>,
              Ken Powell <Ken.Powell@compaq.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello folks,

Here is a stab at an appendix.  It needs proofreading, but
I have to go for now and I thought it would be better to
send something defective for now and touch it up more later.

My opinion is that a Binding Update is needed, and if it takes
another few hundred milliseconds, that's O.K.  So, I retained
that step for the part after the Router Advertisement was
received by the mobile node.  However, this is of course up
for discussion.

I reckon the hard part will be to manage the identification
for the mobile node.  As Hesham mentions, NAI could be used
for this.  However, I am sure that everyone agrees that right
now is not the time for trying to complete that discussion.

Regards,
Charlie P.

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


A. Remote Home Address Configuration

   The method for initializing a mobile node's home addresses on
   power-up or after an extended period of being disconnected from
   the network is beyond the scope of this specification.  Whatever
   procedure is used should result in the mobile node having the same
   stateless or stateful (e.g., DHCPv6) home address autoconfiguration
   information it would have if it were attached to the home network.
   Due to the possibility that the home network could be renumbered
   while the mobile node is disconnected, a robust mobile node would not
   rely solely on storing these addresses locally.

   A mobile node MAY generate a temporary home address using the
   following information:

    -  the subnet prefix from the home network's mobile agent anycast
       address, and

    -  the globally unique interface identifier that would have been
       used to generate the link local address if the mobile node were
       attached directly to the home network.

   Such a temporary address could be used to establish a binding with
   a home agent in the absence of any other known home addresses.  It
   could be created with short valid lifetime and a preferred lifetime
   of zero to ensure a quick transition to other addresses generated
   when stateless or stateful (DHCPv6) address autoconfiguration runs.

   Such a mobile node could initialize by using the following procedure:

    1. Query DNS for the home network's mobile agent anycast address.

    2. Generate a care-of address using stateless or stateful
       autoconfiguration.

    3. Send a Home Agent Address Discovery Request message to the home
       network.

    4. Receive Home Agent Address Discovery Reply message.

    5. MN picks one Home Agent and tunnels an Router Solicitation to it.

          Outer src = care-of address
          Outer dst = Home Agent's global address
          Inner src = 0:0:0:0:0:0:0:0 (unspecified address)
          Inner dst = Home Agent's global address


    6. Home Agent returns a Router Advertisement, covered by AH. An SA
       has to be set up between MN's CoA and the HA. How this is done
       is out of scope, but MN and HA have some shared secret or can be
       verified by some agent.

       The Router Advertisement is returned by tunneling, as follows:

          Outer src = HA's global address
          Outer dst = care-of address
          Outer src = HA's home subnet link-local address
          Inner dst = all-nodes multicast address


    7. Mobile node parses Router Advertisement and configures all
       prefixes and addresses according to the method stated there.  If
       the the M or O flags are set in the router advertisement, follow
       the stateful (DHCPv6) configuration procedures.

    8. Send binding update option(s) to establish bindings for the new
       home addresses.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 17:05:57 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25210
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 17:05:56 -0500 (EST)
Received: from standards (47.234.32.16:2571) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB301B@standards.nortelnetworks.com>; Thu, 9 Nov 2000 16:45:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 92550 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 16:45:42 -0500
Received: from ztxmail03.ztx.compaq.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB3019@standards.nortelnetworks.com>; Thu, 9 Nov 2000 16:45:42
          -0500
Received: by ztxmail03.ztx.compaq.com (Postfix,
          from userid 12345) id 7DCD58C4; Thu,  9 Nov 2000 16:01:59 -0600 (CST)
Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net
          [16.103.129.42]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id
          405A66DF; Thu,  9 Nov 2000 16:01:59 -0600 (CST)
Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service
          (5.5.2652.78) id <WQVS671J>; Thu, 9 Nov 2000 17:01:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Powell, Ken" <Ken.Powell@COMPAQ.COM>
Message-ID:  <C99A689B0CB9D111AF3F0000F8062CCD08FB83C2@zkoexc2.zko.dec.com>
Date:         Thu, 9 Nov 2000 17:01:55 -0500
Reply-To: "Powell, Ken" <Ken.Powell@compaq.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Powell, Ken" <Ken.Powell@compaq.com>
Subject:      Re: [MOBILE-IP] Placement for Binding Update and Home Address opt
              ions
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> Bottom line _proposal_:
>
> Mandatory placements:
>         - Home Address option between Routing and Fragment Headers
>         - Binding Update after ESP.
>
> Comments?

I did a quick comparison to RFC 2460 and the latest Advanced
IPv6 API spec. RFC 2460 recommends the header order listed
below:

   IPv6 header

   Hop-by-Hop Options

   Destination Options (AdvAPI: only if routing header exists)

   Routing
        <--- Charlie: destination option w/ home address here
   Fragment

   Authentication

   Encapsulating Security Payload

   Destination Options <--- Charlie: binding update here

   upper-layer

The advanced API spec currently only allows for 2 destination
option headers.

I was wondering why create another destination option header
for the home address option after the routing header instead
using the existing one before? On the other hand, I
don't know why RFC 2460 put the destination option header
before the routing header.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 17:11:57 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26519
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 17:11:56 -0500 (EST)
Received: from standards (47.234.32.16:2571) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB307E@standards.nortelnetworks.com>; Thu, 9 Nov 2000 16:53:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 92683 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 16:53:01 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB307A@standards.nortelnetworks.com>; Thu, 9 Nov 2000 16:53:00
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA28412;
          Thu, 9 Nov 2000 14:09:18 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eA9M9FH11527; Thu, 9 Nov 2000 14:09:15
          -0800
X-Virus-Scanned:  Thu, 9 Nov 2000 14:09:15 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdEscqlU; Thu, 09 Nov 2000
          14:09:11 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <C99A689B0CB9D111AF3F0000F8062CCD08FB83C2@zkoexc2.zko.dec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A0B208A.4E963FB1@iprg.nokia.com>
Date:         Thu, 9 Nov 2000 14:09:14 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] Placement for Binding Update and Home Address
              options
X-To:         "Powell, Ken" <Ken.Powell@compaq.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Ken,

The reason why to have the Home Address destination
option after the Routing Header is because routers
are not supposed to look at the Home Address option.

The reason that some destination options should be
put before the Routing Header is because some routing
agents might need to look at an "Intermediate
Destination Option", and the routing header addresses
do end up being in the Destination Address field of
the IPv6 header.

I don't know how important it is for the destination
option to be tangible by way of the API, but there
certainly is an easy fix for that problem.  Most of
the direct processing of the Home Address option
requires kernel coding anyway, at least from my vantage
point.  Of course, everyone's kernel could be different,
and they usually are.

Regards,
Charlie P.




"Powell, Ken" wrote:
>
> > Bottom line _proposal_:
> >
> > Mandatory placements:
> >         - Home Address option between Routing and Fragment Headers
> >         - Binding Update after ESP.
> >
> > Comments?
>
> I did a quick comparison to RFC 2460 and the latest Advanced
> IPv6 API spec. RFC 2460 recommends the header order listed
> below:
>
>    IPv6 header
>
>    Hop-by-Hop Options
>
>    Destination Options (AdvAPI: only if routing header exists)
>
>    Routing
>         <--- Charlie: destination option w/ home address here
>    Fragment
>
>    Authentication
>
>    Encapsulating Security Payload
>
>    Destination Options <--- Charlie: binding update here
>
>    upper-layer
>
> The advanced API spec currently only allows for 2 destination
> option headers.
>
> I was wondering why create another destination option header
> for the home address option after the routing header instead
> using the existing one before? On the other hand, I
> don't know why RFC 2460 put the destination option header
> before the routing header.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 17:32:53 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01810
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 17:32:52 -0500 (EST)
Received: from standards (47.234.32.16:2571) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB3128@standards.nortelnetworks.com>; Thu, 9 Nov 2000 17:14:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 92922 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 17:14:47 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB3126@standards.nortelnetworks.com>; Thu, 9 Nov 2000 17:14:46
          -0500
Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id OAA05402; Thu, 9 Nov 2000 14:31:02
          -0800 (PST)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by
          sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with
          ESMTP id OAA01054; Thu, 9 Nov 2000 14:31:01 -0800 (PST)
Received: from quantam (dsl-194-126.Eng.Sun.COM [129.146.194.126]) by
          jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id
          eA9MV06209828; Thu, 9 Nov 2000 14:31:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  "mohan.parthasarathy" <Mohan.Parthasarathy@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.973809075.13092.mohanp@jurassic>
Date:         Thu, 9 Nov 2000 14:31:15 -0800
Reply-To: "mohan.parthasarathy" <Mohan.Parthasarathy@eng.sun.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "mohan.parthasarathy" <Mohan.Parthasarathy@eng.sun.com>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Charlie Perkins <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" <3A0A9C47.A9DD5107@iprg.nokia.com>

> Hello,
>
> I'm trying to follow up on some discussion a few days ago
> about this point.  The last indication I received was that a
> node receiving a packet with an ESP header should be
> able to decrypt the payload using only the SPI and the
> destination IPv6 address.  I had always thought that the
> receiving node would want to use the mobile node's home
> address to select the correct security association.  Recent
> messages indicate that other implementations do not use
> that information; then they presumably do not use the
> IPv6 source address at all when identifying the correct
> security association.
>
RFC 2401, section 5.2.1 step(2) does mandate verifying the
SA with the source address in the IPv6 header. There are
actually two parts. One is locating the SA which uses
only SPI and destination address. The other is verifying whether
the SA is right or not. For this, you need to know the source
address.

The conclusion is it does not really matter where the home
address option is. As SA verification could mean more than
just verifying addresses e.g. you may have to verify ports,
then you need to get all your SAs and then finally do
the verification as ports are not visible in the case of ESP.
This means that Home address option would be traversed
while doing so.

> This is a crucial point, and a decision should be made ASAP.
>
> There seem to be two additional relevant points:
>
> - We should pick a placement for the Home Address option,
>    and make it mandatory.  Doing so will simplify the implementation
>    for all the billions of correspondent nodes of the future.  We want
>    that implementation to be as simple as possible.  The two
>    candidate placements are either after ESP, possibly in the
>    same options header as the Binding Update, or else before
>    the Fragment Header.
>
As there is no real benefit in putting it after AH/ESP header, i would
suggest leaving it as it is i.e before AH/ESP header.

-mohan


> - Putting the information after ESP will make things substantially
>    more complicated for possible firewall management.
>
> Based on this evidence, I am leaning towards a mandatory placement
> before the Fragment Header.  As soon as I can determine consensus
> on this point, I am ready to issue a revised (and hopefully last)
> Internet Draft for Mobile IPv6.
>
> Thanks for your comments!
>
> Regards,
> Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov  9 21:56:41 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05809
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Nov 2000 21:56:41 -0500 (EST)
Received: from standards (47.234.32.16:4609) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB322B@standards.nortelnetworks.com>; Thu, 9 Nov 2000 21:38:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 93268 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 21:38:26 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB3229@standards.nortelnetworks.com>; Thu, 9 Nov 2000 21:38:25
          -0500
Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id SAA05538; Thu, 9 Nov 2000 18:54:42
          -0800 (PST)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.89.31]) by
          sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with
          ESMTP id SAA03076; Thu, 9 Nov 2000 18:54:41 -0800 (PST)
Received: from quantam (dsl-194-126.Eng.Sun.COM [129.146.194.126]) by
          jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id
          eAA2se6249527; Thu, 9 Nov 2000 18:54:40 -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  "mohan.parthasarathy" <Mohan.Parthasarathy@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.973824894.10087.mohanp@jurassic>
Date:         Thu, 9 Nov 2000 18:54:54 -0800
Reply-To: "mohan.parthasarathy" <Mohan.Parthasarathy@eng.sun.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "mohan.parthasarathy" <Mohan.Parthasarathy@eng.sun.com>
Subject:      Re: [MOBILE-IP] Swapping care-of address and home address
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" <3A0ADE49.DA37A9AA@iprg.nokia.com>

Charlie,

All we need to do is protect both the CoA and the Home Address.
It does not really matter where these addresses are found i.e
whether it is found in the Ipv6 header or the Home Address option.

For AH calculation to be same on both the sending and
receiving side, we need to define what the Ipv6 source address
would contain and what the home address option would contain.
To keep the draft simple, i suggest the following :

"While computing the AH, the Ipv6 source address field MUST
 contain the Home address and the Home address option MUST
 contain the Care of Address."

How you achieve the above is implementation dependent.

-mohan


> Hello folks,
>
> Here's another conundrum that has to be settled.
>
> Problem:
>         How is AH calculated when care-of address is
>         initially present in the IPv6 header, and the
>         Home Address option is present.
>
> Proposal:
>         Exchange the care-of address in the IPv6 header
>         with the home address in the Home Address option.
>         Then, when AH is calculated on the receiving end,
>         the care-of address will be present in the data
>         field of the Home Address option, and the home
>         address will be present in the IPv6 header.
>
> Also:
>         When the Binding Update is present, a Home Address
>         option is mandatory.  The above proposal means that
>         when the inbound Binding Update processing occurs,
>         the care-of address has to be retrieved from the
>         Home Address option instead of the IPv6 header.
>
>
> Thinking about the alternatives, while required, is enough
> to give one a migraine headache.  For those who dare go on,
> please don't say I didn't warn you.
>
> Alternative 1: Keep both in place
>         This means that all subsequent processing has to be
>         special cased depending on whether or not a Home
>         Address option has been processed.  The code I have
>         seen (e.g., protocol-switch based code) has a hard
>         time dealing with this.
>
> Alternative 2: Copy the home address into the IPv6 header,
>         and do not copy the care-of address into the Home
>         Address option.  This doesn't simplify anything, and
>         just makes it harder to retrieve the care-of address.
>
>
> I'm not exactly sure whether there has already been agreement
> on this or not.  I know there's been plenty of discussion.
> There seems to be three main camps:
>         - Leave the fields where they are, and
>         - Exchange them
>         - Do almost anything reasonable, but pick something
>           definite and make it mandatory.
>
> I hope this qualifies to satisfy those in the last two camps,
> at least.  And, I think that there is general agreement that
> the current wording of the draft has to be changed somehow
> to make it clear which alternative is being specified.
>
> Regards,
> Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 01:42:20 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27121
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 01:42:19 -0500 (EST)
Received: from standards (47.234.32.16:2241) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB3384@standards.nortelnetworks.com>; Fri, 10 Nov 2000 1:23:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 93668 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 01:23:57
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB3382@standards.nortelnetworks.com>; Fri, 10 Nov 2000 1:23:57
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Thu, 09 Nov 2000 22:39:31 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <W3JZRCRP>; Thu, 9 Nov 2000 22:40:15 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA8011AC2B2@red-msg-06.redmond.corp.microsoft.com>
Date:         Thu, 9 Nov 2000 22:40:13 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] Binding Cache entries per IPv6 address at Corresp
              ondent Node
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> > A CN/HA with more than one interface address may get independent BUs
> > sent to it. The mobile node will consider them as different
> nodes and
> > keep one BUL entry for each of them. Especially, it will
> use independent
> > sets of sequence numbers, which in turn will cause the
> receiving CN/HA
> > to get very confused (and not accept the BUs).
> >
> > This can happen to any host/router that has multiple
> interface addresses
> > of the same scope as the home address, not only nodes with multiple
> > interfaces.
> >
> > My suggestion is to keep a Binding Cache on a CN/HA for
> every interface
> > address that's assigned, and to clear this out in the draft under
> > "Conceptual structs". Currently you can read both do and
> don't out of
> > the spec. It will be more complex, but it is the logical
> way to do it.
>
> Here is what I have added to the Internet Draft, as you suggested:
>
>
>
>  Binding Cache
>
>          A cache, maintained by each IPv6 node, of bindings for other
>          nodes.  A separate Binding Cache SHOULD be maintained by each
>          IPv6 node for each of its IPv6 addresses.

This is an interesting problem! First let me confirm: my understanding is
that a MN can only have a single mapping from HA to CoA, because it can send
its home agent a single such binding. In particular, a MN can not reasonably
use one CoA when talking to one correspondent and a different CoA when
talking to a different correspondent.

Previously the Binding Cache Entry maintained a mapping HA -> CoA. Your
suggested solution means that now the Binding Cache Entry is effectively a
triple, besides the HA & CoA there is also the correspondent address CA. The
mapping is (CA, HA) -> CoA. So when the correspondent looks up a Binding
Cache Entry, it finds one with the right CA (source address) and HA
(original destination) and gets the mapping to a CoA.

This means that if the correspondent sends a packet to the mobile using a
new CA2, then it might not find a Binding Cache Entry (and the packet will
be routed via the home agent), even if it has a Binding Cache Entry for CA1.
(There are scenarios involving anycast where this would be common.)

One solution would be to say, although there may be multiple Binding Cache
Entries for a HA -> CoA mapping, one per CA (to track the sequence numbers
properly), when looking up a Binding Cache Entry you can find & use any of
them regardless of the packet's source address.

Another solution (pretty much equivalent but conceptualized differently)
would be to say, there is one Binding Cache Entry for the mapping HA -> CoA,
but the single Binding Cache Entry can contain a sequence number per CA.
(I'm not sure if the binding lifetime needs to be per CA or not.)

Rich


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 01:42:21 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27130
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 01:42:20 -0500 (EST)
Received: from standards (47.234.32.16:2241) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB339A@standards.nortelnetworks.com>; Fri, 10 Nov 2000 1:25:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 93696 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 01:25:04
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB3398@standards.nortelnetworks.com>; Fri, 10 Nov 2000 1:25:04
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Thu, 09 Nov 2000 22:20:30 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <W3JZQ07T>; Thu, 9 Nov 2000 21:55:14 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA8011AC2B1@red-msg-06.redmond.corp.microsoft.com>
Date:         Thu, 9 Nov 2000 21:54:09 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Charlie Perkins <charliep@IPRG.nokia.com>
X-cc:         Francis Dupont <Francis.Dupont@inria.fr>,
              Vijay Devarapalli <vijayd@iprg.nokia.com>,
              "mohan.parthasarathy" <Mohan.Parthasarathy@eng.sun.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

[Charlie]
> I'm trying to follow up on some discussion a few days ago
> about this point.  The last indication I received was that a
> node receiving a packet with an ESP header should be
> able to decrypt the payload using only the SPI and the
> destination IPv6 address.  I had always thought that the
> receiving node would want to use the mobile node's home
> address to select the correct security association.  Recent
> messages indicate that other implementations do not use
> that information; then they presumably do not use the
> IPv6 source address at all when identifying the correct
> security association.

RFC2401 compliant implementations find the correct security association
based on the destination address, SPI, and IPsec header type.

> This is a crucial point, and a decision should be made ASAP.
>
> There seem to be two additional relevant points:
>
> - We should pick a placement for the Home Address option,
>    and make it mandatory.  Doing so will simplify the implementation
>    for all the billions of correspondent nodes of the future.  We want
>    that implementation to be as simple as possible.  The two
>    candidate placements are either after ESP, possibly in the
>    same options header as the Binding Update, or else before
>    the Fragment Header.
>
> - Putting the information after ESP will make things substantially
>    more complicated for possible firewall management.

ESP might make firewall management more complicated, I won't dispute that.
But my point is that users & admins should have a choice of using AH or ESP.
In some environments, the appropriate choice might be ESP. In other
environments, AH might be an appropriate choice.

If the Home Address option follows an AH header, a firewall can still find
it easily. So if you want to be friendly to firewalls, have a policy of
using AH. But please don't prevent others from using ESP.

[Mohan]
> As there is no real benefit in putting it after AH/ESP header, i would
> suggest leaving it as it is i.e before AH/ESP header.

There is real benefit. If you put the Home Address option after, then you
can use either AH or ESP depending your policy/whim. If you put the Home
Address option before, then you must use AH because ESP won't protect it.

So to summarize, I think the spec should say the Home Address option and the
Binding Update option appear in the same destination options header, after
the IPsec header(s), and if AH is not used, then the Binding Update must
have a Care-Of Address suboption.

Rich


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 01:52:30 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03705
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 01:52:29 -0500 (EST)
Received: from standards (47.234.32.16:2241) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB3428@standards.nortelnetworks.com>; Fri, 10 Nov 2000 1:34:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 93881 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 01:34:05
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB3426@standards.nortelnetworks.com>; Fri, 10 Nov 2000 1:34:05
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Thu, 09 Nov 2000 22:49:39 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <W3JZRDQ5>; Thu, 9 Nov 2000 22:50:23 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA8011AC2B3@red-msg-06.redmond.corp.microsoft.com>
Date:         Thu, 9 Nov 2000 22:49:36 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Charlie Perkins <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> > - Putting the information after ESP will make things substantially
> >    more complicated for possible firewall management.
>
> ESP might make firewall management more complicated, I won't
> dispute that. But my point is that users & admins should have
> a choice of using AH or ESP. In some environments, the
> appropriate choice might be ESP. In other environments, AH
> might be an appropriate choice.
>
> If the Home Address option follows an AH header, a firewall
> can still find it easily. So if you want to be friendly to
> firewalls, have a policy of using AH. But please don't
> prevent others from using ESP.

Aha, I just got why you want the Home Address before a Fragment header for
firewalls: so they can see the Home Address in every packet even fragments.
Duh. And the Fragment header has to be before the IPsec headers. Since ESP
isn't friendly to firewalls anyway, firewall-friendliness is only a concern
for AH. This means two header orders make sense:
a) IPv6, Home Address, possible Fragment, AH, Binding Update, Transport
b) IPv6, possible Fragment, ESP (auth and/or encryption), Home Address &
Binding Update with CoA suboption, Transport

Rich


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 03:14:22 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19512
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 03:14:21 -0500 (EST)
Received: from standards (47.234.32.16:4439) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB353D@standards.nortelnetworks.com>; Fri, 10 Nov 2000 2:56:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 94243 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 02:56:06
          -0500
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBB353B@standards.nortelnetworks.com>; Fri, 10 Nov 2000 2:56:05
          -0500
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP
          id eAA8CKZ04976; Fri, 10 Nov 2000 09:12:24 +0100 (MET)
Received: from era.ericsson.se by era-t.ericsson.se
          (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id JAA12514; Fri, 10 Nov 2000 09:12:20
          +0100
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
References: <3A0AC4E8.CDE13238@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Mattias Pettersson <mattias.pettersson@ERA.ERICSSON.SE>
Message-ID:  <3A0BADD9.B3FEEC41@era.ericsson.se>
Date:         Fri, 10 Nov 2000 09:12:09 +0100
Reply-To: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Radio Systems AB
Subject:      Re: [MOBILE-IP] Binding Cache entries per IPv6 address at
              Correspondent Node
X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Charlie,

"Charles E. Perkins" wrote:

> Here is what I have added to the Internet Draft, as you suggested:
>
>  Binding Cache
>
>          A cache, maintained by each IPv6 node, of bindings for other
>          nodes.  A separate Binding Cache SHOULD be maintained by each
>          IPv6 node for each of its IPv6 addresses.
>
>                       ...........
>
>                  The contents of all of a node's Binding Cache entries,
>          for each of its IPv6 addresses, must be cleared when the node
>          reboots.
>
> In addition, I have changed several places where it seems to
> read better to allow multiple Binding Caches (one per IPv6 address).
>
> Does this fix the problem, without introducing any new problems?
>
Perfect! I can't see a problem now. And there should be nothing on the
Mobile's side in the spec to update, such as the Binding Update or
Binding Update List.

/Mattias


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 03:25:45 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24319
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 03:25:45 -0500 (EST)
Received: from standards (47.234.32.16:4439) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB35D0@standards.nortelnetworks.com>; Fri, 10 Nov 2000 3:07:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 94440 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 03:07:05
          -0500
Received: from odin2.bull.net by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB35CE@standards.nortelnetworks.com>; Fri, 10 Nov 2000 3:07:04
          -0500
Received: from ecbull20.frec.bull.fr (ecbull20.frec.bull.fr [129.183.4.3]) by
          odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA12292; Fri, 10 Nov 2000
          09:29:11 +0100
Received: from isatis.frec.bull.fr (isatis.frec.bull.fr [129.183.144.1]) by
          ecbull20.frec.bull.fr (8.9.2/8.9.1) with ESMTP id JAA19520; Fri, 10
          Nov 2000 09:22:51 +0100
Received: from bull.net (localhost [127.0.0.1]) by isatis.frec.bull.fr
          (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA128758; Fri, 10 Nov 2000
          09:22:50 +0100 (NFT)
X-Mailer: Mozilla 4.06 [en] (X11; I; AIX 4.2)
MIME-Version: 1.0
References: <7695E2F6903F7A41961F8CF888D87EA8011AC2B3@red-msg-06.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Aime.Le-Rouzic@BULL.NET
Message-ID:  <3A0BB05A.1CEE621A@bull.net>
Date:         Fri, 10 Nov 2000 09:22:50 +0100
Reply-To: AIme Le-Rouzic <Aime.Le-Rouzic@bull.net>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: AIme Le-Rouzic <Aime.Le-Rouzic@bull.net>
Organization: Bull
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Richard Draves <richdr@microsoft.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Richard Draves wrote:
>
> > > - Putting the information after ESP will make things substantially
> > >    more complicated for possible firewall management.
> >
> > ESP might make firewall management more complicated, I won't
> > dispute that. But my point is that users & admins should have
> > a choice of using AH or ESP. In some environments, the
> > appropriate choice might be ESP. In other environments, AH
> > might be an appropriate choice.
> >
> > If the Home Address option follows an AH header, a firewall
> > can still find it easily. So if you want to be friendly to
> > firewalls, have a policy of using AH. But please don't
> > prevent others from using ESP.
>
> Aha, I just got why you want the Home Address before a Fragment header for
> firewalls: so they can see the Home Address in every packet even fragments.
> Duh. And the Fragment header has to be before the IPsec headers. Since ESP
> isn't friendly to firewalls anyway, firewall-friendliness is only a concern
> for AH. This means two header orders make sense:
> a) IPv6, Home Address, possible Fragment, AH, Binding Update, Transport
> b) IPv6, possible Fragment, ESP (auth and/or encryption), Home Address &
> Binding Update with CoA suboption, Transport

 I don't think so, it needs to be friendly with firewalls  having a
policy AH (for BU and BA) and having a policy ESP (for datas).For that
the Home Address header has to be before the security header ESP to
allow firewalls let
the packet goes out or enter.

Home address header has to be seen like an extension of the IPheader.

What's the matter with that because on the other way the routing header
carrying the home address is always before the security header even
using ESP in transport mode.


We need to remember MobileIPv6 will be successful if it allows the user
to protect its datas. The solution has to work when we have the two
security headers in the packet AH +ESP. We need to offer the firewall to
control them at least by the ip address.

Best regards

PS:
Other things , only BU and BA are required to be authenticated. A better
security would be if also RH, HA, BR were recommanded to be
authenticated.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 04:34:08 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23073
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 04:34:08 -0500 (EST)
Received: from standards (47.234.32.16:1942) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB3670@standards.nortelnetworks.com>; Fri, 10 Nov 2000 4:15:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 94644 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 04:15:49
          -0500
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB366E@standards.nortelnetworks.com>; Fri, 10 Nov 2000
          4:15:48 -0500
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP
          id eAA9W6t16456; Fri, 10 Nov 2000 10:32:06 +0100 (MET)
Received: from era.ericsson.se by era-t.ericsson.se
          (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA15258; Fri, 10 Nov 2000 10:32:06
          +0100
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
References: <C99A689B0CB9D111AF3F0000F8062CCD08FB83C0@zkoexc2.zko.dec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Mattias Pettersson <mattias.pettersson@ERA.ERICSSON.SE>
Message-ID:  <3A0BC08A.665F0B59@era.ericsson.se>
Date:         Fri, 10 Nov 2000 10:31:54 +0100
Reply-To: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Radio Systems AB
Subject:      Re: [MOBILE-IP] Binding Cache entries per IPv6 address at
              Correspondent Node
X-To:         "Powell, Ken" <Ken.Powell@compaq.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

"Powell, Ken" wrote:
>
> I'm not sure how the clause "for each of its IPv6 addresses"
> applies when the prefix length is non-zero. In this case, a
> single binding covers multiple addresses.

It's the CN/HA that keeps a BC for each of its _own_ addresses. Not one
for every address the MN has. Or do I misunderstand you?

This led me to another question of the draft:

     Prefix Length

         The Prefix Length field is valid only for a "home registration"
         Binding Update; this field MUST be zero if the Home
         Registration (H) bit is not set in the Binding Update.  The
         Prefix Length field is set by the sending mobile node to the
         (nonzero) length of its subnet prefix in its home address
         (given in the Home Address option in the packet) to request
         its home agent to use the interface identifier in the mobile
         node's home address (the remaining low-order bits after the
         indicated subnet prefix) to form all other home addresses for
         the mobile node on the home link.  The home agent becomes the
         home agent not only for the individual home address given in
         this binding, but also for all other home addresses for this
         mobile node formed from this interface identifier.  That is,
         for each on-link prefix on the home link, the home agent uses
         the interface identifier to form other valid addresses for
         the mobile node on the home link, and acts as a home agent
         also for those addresses.  In addition, the home agent forms
         the link-local address and site-local address corresponding
         to this interface identifier, and defends each for purposes
         of Duplicate Address Detection.  The home agent also performs
         Duplicate Address Detection on each such address as part of
         the home registration processing (before returning the Binding
         Acknowledgement), if the Duplicate Address Detection (D) bit
         is set in the Binding Update.  Details of this operation are
         described in Section 9.3.


One BU is, according to the draft, enough to register all home addresses
formed by prefixes on the home link, plus site- and link-local. However,
I feel there is a slight gap in the protocol on what home addresses
that's actually been registered. Is it pointed out somewhere else in the
spec where the HA explicitly tells the MN about the addresses
registered, so that the MN can prepare to receive packets to these
addresses? Or, as I guess is assumed, the HA should already have
informed the MN in an RA about what prefixes are valid.

Though, if the MN wants total control of the addresses being registered,
I guess the MN can set prefixlen to zero and register each address in a
separate BU.

/Mattias


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 04:51:24 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00267
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 04:51:24 -0500 (EST)
Received: from standards (47.234.32.16:1942) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB36C2@standards.nortelnetworks.com>; Fri, 10 Nov 2000 4:33:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 94751 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 04:33:21
          -0500
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBB36C0@standards.nortelnetworks.com>; Fri, 10 Nov 2000 4:33:21
          -0500
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP
          id eAA9naZ02174; Fri, 10 Nov 2000 10:49:40 +0100 (MET)
Received: from era.ericsson.se by era-t.ericsson.se
          (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA15891; Fri, 10 Nov 2000 10:49:35
          +0100
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
References: <3A0B192A.472756C1@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Mattias Pettersson <mattias.pettersson@ERA.ERICSSON.SE>
Message-ID:  <3A0BC4A3.30BD5E2A@era.ericsson.se>
Date:         Fri, 10 Nov 2000 10:49:23 +0100
Reply-To: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Radio Systems AB
Subject:      Re: [MOBILE-IP] Appendix
X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
X-cc:         Ken Powell <Ken.Powell@compaq.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,

"Charles E. Perkins" wrote:
>
> Hello folks,
>
> I reckon the hard part will be to manage the identification
> for the mobile node.  As Hesham mentions, NAI could be used
> for this.  However, I am sure that everyone agrees that right
> now is not the time for trying to complete that discussion.
>

I think such a protocol is all above Mobile IPv6 and can without problem
be left out of this draft.


>    Such a mobile node could initialize by using the following procedure:
>
>     1. Query DNS for the home network's mobile agent anycast address.
>
>     2. Generate a care-of address using stateless or stateful
>        autoconfiguration.

In order to query the DNS the MN should probably need a care-of address,
so please swap 1 and 2.

>     7. Mobile node parses Router Advertisement and configures all
>        prefixes and addresses according to the method stated there.  If
>        the the M or O flags are set in the router advertisement, follow
>        the stateful (DHCPv6) configuration procedures.

Currently, as I said earlier, DHCPv6 won't really support such off-link
and off-site configuration, at least to my knowledge. This is out of
scope (an easy escape... someone has to fix this later, though).

>
>     8. Send binding update option(s) to establish bindings for the new
>        home addresses.

/Mattias


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 05:05:43 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06245
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 05:05:43 -0500 (EST)
Received: from standards (47.234.32.16:1942) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB3747@standards.nortelnetworks.com>; Fri, 10 Nov 2000 4:46:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 94925 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 04:46:34
          -0500
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB3745@standards.nortelnetworks.com>; Fri, 10 Nov 2000
          4:46:34 -0500
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP
          id eAAA2qt09100; Fri, 10 Nov 2000 11:02:52 +0100 (MET)
Received: from era.ericsson.se by era-t.ericsson.se
          (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id LAA16338; Fri, 10 Nov 2000 11:02:51
          +0100
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
References: <C99A689B0CB9D111AF3F0000F8062CCD08FB83BF@zkoexc2.zko.dec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Mattias Pettersson <mattias.pettersson@ERA.ERICSSON.SE>
Message-ID:  <3A0BC7C0.2B2E4241@era.ericsson.se>
Date:         Fri, 10 Nov 2000 11:02:40 +0100
Reply-To: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Radio Systems AB
Subject:      Re: [MOBILE-IP] DAD
X-To:         "Powell, Ken" <Ken.Powell@compaq.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

"Powell, Ken" wrote:
>
> Charlie,
>
> I think the problem is that the home agent will only
> defend against a duplicate address when there is a binding
> with the mobile node. This is something that the base specs
> are not concerned with. Therefore, it might make sense
> to add a statement like:
>
>   The home agent will only defend against a duplicate
>   address when there is a binding with the mobile node.
>   Therefore, the mobile node MUST treat creation of a
>   new binding with the home agent using an existing home
>   address the same as creation of a new home address.
>

Thanks, Ken.

/Mattias

> > Why isn't this sufficient?
> >
> > Regards,
> > Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 05:32:07 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17200
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 05:32:06 -0500 (EST)
Received: from standards (47.234.32.16:1942) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB37B8@standards.nortelnetworks.com>; Fri, 10 Nov 2000 5:12:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 95072 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 05:12:42
          -0500
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBB37B5@standards.nortelnetworks.com>; Fri, 10 Nov 2000 5:12:42
          -0500
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP
          id eAAAT0Z00731; Fri, 10 Nov 2000 11:29:00 +0100 (MET)
Received: from era.ericsson.se by era-t.ericsson.se
          (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id LAA17124; Fri, 10 Nov 2000 11:29:00
          +0100
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
References: <7695E2F6903F7A41961F8CF888D87EA8011AC2B2@red-msg-06.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Mattias Pettersson <mattias.pettersson@ERA.ERICSSON.SE>
Message-ID:  <3A0BCDE0.5EAE5BCD@era.ericsson.se>
Date:         Fri, 10 Nov 2000 11:28:48 +0100
Reply-To: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Radio Systems AB
Subject:      Re: [MOBILE-IP] Binding Cache entries per IPv6 address at
              Correspondent Node
X-To:         Richard Draves <richdr@microsoft.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Richard Draves wrote:
>
> >  Binding Cache
> >
> >          A cache, maintained by each IPv6 node, of bindings for other
> >          nodes.  A separate Binding Cache SHOULD be maintained by each
> >          IPv6 node for each of its IPv6 addresses.
>
> This is an interesting problem! First let me confirm: my understanding is
> that a MN can only have a single mapping from HA to CoA, because it can send
> its home agent a single such binding. In particular, a MN can not reasonably
> use one CoA when talking to one correspondent and a different CoA when
> talking to a different correspondent.

Indeed it can. I think that it is a likely case, although very advanced.
There would be a point in registering different CoAs with different CNs,
depending on e.g. where you'd want your traffic to flow. In the
extension, there could be a need to not only register a binding for a
home address, but also for a port number.

> Previously the Binding Cache Entry maintained a mapping HA -> CoA. Your
> suggested solution means that now the Binding Cache Entry is effectively a
> triple, besides the HA & CoA there is also the correspondent address CA. The
> mapping is (CA, HA) -> CoA. So when the correspondent looks up a Binding
> Cache Entry, it finds one with the right CA (source address) and HA
> (original destination) and gets the mapping to a CoA.

Yes.

>
> This means that if the correspondent sends a packet to the mobile using a
> new CA2, then it might not find a Binding Cache Entry (and the packet will
> be routed via the home agent), even if it has a Binding Cache Entry for CA1.
> (There are scenarios involving anycast where this would be common.)

Yes.

>
> One solution would be to say, although there may be multiple Binding Cache
> Entries for a HA -> CoA mapping, one per CA (to track the sequence numbers
> properly), when looking up a Binding Cache Entry you can find & use any of
> them regardless of the packet's source address.

I'm not sure what the MN would say about this mixing. Today the criteria
for sending a BU to a CN is if it detects that a packet is tunneled via
the HA. So the MN wouldn't check that a source address is different from
the CA in the BUL. Still, it's on the edge to what is good behaviour...

>
> Another solution (pretty much equivalent but conceptualized differently)
> would be to say, there is one Binding Cache Entry for the mapping HA -> CoA,
> but the single Binding Cache Entry can contain a sequence number per CA.

It is a possible implementation way.

> (I'm not sure if the binding lifetime needs to be per CA or not.)

It has to.

/Mattias


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 07:30:14 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00417
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 07:30:13 -0500 (EST)
Received: from standards (47.234.32.16:2561) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB38D9@standards.nortelnetworks.com>; Fri, 10 Nov 2000 7:11:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 95456 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 07:11:49
          -0500
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBB38D7@standards.nortelnetworks.com>; Fri, 10 Nov 2000 7:11:48
          -0500
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP
          id eAACS7Z25689; Fri, 10 Nov 2000 13:28:07 +0100 (MET)
Received: from era.ericsson.se by era-t.ericsson.se
          (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id NAA21148; Fri, 10 Nov 2000 13:28:07
          +0100
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
References: <C99A689B0CB9D111AF3F0000F8062CCD08FB83BE@zkoexc2.zko.dec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Mattias Pettersson <mattias.pettersson@ERA.ERICSSON.SE>
Message-ID:  <3A0BE9CB.9A933E2F@era.ericsson.se>
Date:         Fri, 10 Nov 2000 13:27:55 +0100
Reply-To: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Radio Systems AB
Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home networkrenumbe
              ring
X-To:         "Powell, Ken" <Ken.Powell@compaq.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Ken,

I believe Charlie's new Appendix sums up this discussion pretty well. I
haven't got all my requests in it, but I have to say it is an ok middle
way.

"Powell, Ken" wrote:
>
> Mattias,
>
> I fear we are not resolving this very fast. The only
> clean solution I see that would satisfy both of us
> is to use tunnels for RS/RA, but that means plenty
> of work real fast. I don't want to start a concrete
> proposal unless others think its worth the effort.
>
> Detailed comments below.
>
> > -----Original Message-----
> > From: Mattias Pettersson [mailto:mattias.pettersson@era.ericsson.se]
> > Sent: Thursday, November 09, 2000 9:29 AM
> > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: [MOBILE-IP] How Mobile IPv6 should handle home
> > networkrenumbe ring
> >
> >
> > Hi Ken,
> >
> > "Powell, Ken" wrote:
> >
> > > Mattias,
> > >
> > > I think you have a very important initialization concern,
> > > primarily because it impacts the way RS's and RA's are
> > > sent between the home agent and the mobile node. It boils
> > > down to a question of can we assume the mobile node will
> > > always have a home address before the first RS/RA exchange?
> > > I hope so, because if not, the technique for sending RS/RA
> > > is broken. Further details below (along with plenty of other
> > > stuff).
> > >
> >
> > I would like the option to let the MN configure it's home
> > address as if it was at home, even if it is not at home.
>
> Yes, I was shooting for that goal too.
>
> >
> > There are two different uses of RS/RA:
> >
> > 1. HA sends RA to MN to synchronize MN with renumbering. An
> > ack is needed. BU from MN to HA in return has been chosen for
> > this. Both RA and BU needs AH. We could theoretically choose
> > another ack method.
> >
> > 2. MN sends RS to HA to learn on home link autoconfiguration
> > (prefixes, address configuration method, etc). HA replies
> > with RA. We don't need a BU after this. RS doesn't necessarily
> > need a AH, but the RA must have it. We could secure it by other
> > means than using the home address.
>
> I think unless we find another ACK method, I would prefer to
> keep the BU at the end of use 2. This is a tradeoff between
> simplicity and efficiency (i.e., "always ACK" vs "ACK except
> under certain conditions").
>
> >
> > >
> > > Following your proposed list of initialization steps:
> > >
> > > > 1. The MN finds out its home prefix.
> > >
> > > One possible option for this was to statically configure in
> > > the mobile node the fully qualified domain name of the home
> > > agent's anycast address. This would allow the mobile node to:
> > >
> > > 1a. Query DNS for the home agent's anycast address.
> > > 1b. Temporarily use the prefix from the home agent's
> > >     anycast address for the home subnet prefix.
> > > 1c. Use the temporary home subnet prefix and a globally
> > >     unique interface id to autoconfigure a temporary home
> > >     subnet address for the mobile node.
> > >
> > > I'm hoping for a better technique to be defined in the
> > > future possibly using AAA that covers IPsec requirements
> > > as well.
> > >
> >
> > Ok. I accept this as one possible way.
> >
> > >
> > > > 2. MN performs DHAAD to find unicast address of an HA.
> > > > 3. MN sends RS to HA.
> > > > 4. HA sends RA with prefix list to MN.
> > >
> > > Given the current method of how RS and RA are exchanged
> > > between the mobile node and home agent, you have to have
> > > a global scope home address for the mobile node by step 3.
> > > You also have to have a valid binding between the mobile
> > > node and the home agent for the home agent to return the
> > > RA. Therefore, it makes sense for the mobile node to
> > > send the BU option for its temporary address with the
> > > initial RS.
> >
> > Yes, given the current method. But if I suggest a new way
> > of automagically configure the home address, exactly as it
> > would have been done on the home link, the current method
> > has to be slightly modified. I think we introduce more
> > modularity/independence if MIPv6 can make use of existing
> > address allocation methods, rather than introducing a new,
> > still not sorted out, method that only MNs use.
>
> OK, I think we have the same objectives here.
>
> > >
> > > > 5. MN builds Home Addresses for all prefixes, by using
> > > >address method stated in prefix info.
> > > > 6. MN registers each Home Address.
> > > > 7. HA might help in address configuration (e.g. DAD)
> > > > 8. DNS should be updated, depending on address configuration
> > > > method (it should be done by the MN at this point, not
> > > > earlier, IMO).
> > > >
> > > > Ok. Let's agree on leaving the big issues out of scope.
> > >
> > > Would listing such steps in an appendix be OK with you?
> >
> > Fine.
> >
> > > > Home Prefix (needed to find Home Agents) conf alts:
> > > > 1A. Manual:
> > > >     - won't survive home network renum when MN is off.
> > > > 1B. Always start home or user interaction (button...):
> > > >     - same, plus need to start at home, a difficult demand
> > > > 1C. AAA:
> > > >     - will survive anything.
> > >
> > > I have no idea what AAA does for us on this. I wouldn't
> > > assume it could be used as an alternative to stateless
> > > address autoconfiguration or DHCPv6.
> > >
> >
> > Here we are talking about finding out the home prefix, not
> > the home address.
> >
> > Please see Hesham's comment in another mail.
>
> Is the real goal to find the home agents, not necessarily
> the home prefixes? Perhaps thats what confused me. I
> consider a mobile would want to get most of its home
> prefix information, complete with lifetimes and flags,
> from stateless or statefull address autoconfiguration
> later on.
>
> >
> > >
> > > Would you add the following as another option?
> > >
> > >   1D. Store prefix in DNS.
> > >        - Must assume a prefix length.
> >
> > Ok.
> >
> > > >
> > > > Home Address conf alts:
> > >
> > > Why have two separate lists for home prefix and home address?
> > > It seems to me the technique for determining the home address is
> > > closely tied to the method for determining home prefix.
> >
> > No. You need the home prefix to find a home agent that can
> > tell you in an RA how to configure your home address.
>
> I think you only need a single home agent anycast address.
> The address can be derived from the prefix if you have one,
> but in many cases, it could be easier to get the anycast
> address directly.

If you are querying the DNS, yes anycast addresses are better.

>
> >
> > > > 2A. Manual:
> > > >     - not the best idea. MN can't check its Home Address
> > > >       for DAD.
> > >
> > > DAD must be used even with manual address configuration.
> >
> > Charlie and others: I can't find anywhere in the I-D that the MN
> > is required to check its Home Address for DAD, other that during
> > renumbering. If the MN is given an address from start (hard coded
> > or statelessly created by combining home prefix and interface
> > token), it must set the D-flag in the initial BU to the HA. It
> > must do this every time the HA doesn't guard the address.
>
> Saw your other message on this, good catch.
>
> >
> > The current spec will only work if the MN at day 1 starts on the home
> > subnet.
> >
> > > >     - What is the relationship between a manual address and
> > > >       the renumbered autoconfigured address?
> > > > 2B. Autoconf by RA from Home Link (either directly from Home
> > > >     Link or tunneled by HA):
> > > >     - MN will be configured just as if it was home.
> > > > 2C. AAA:
> > > >     - then addresses are configured and distributed by other
> > > >       means than IPv6 ND autoconf (state{ful,less})
> > > >     - if renumbering occurs MN must get new address though
> > > >        AAA rather than RA.
> > >
> > > Could AAA be defined to work with stateless address
> > > autoconfiguration or DHCPv6 instead of as an alternative?
> > > Perhaps AAA could somehow bootstrap these other mechanisms.
> > > I know nothing about AAA beyond the idea that it provides
> > > information necessary to establish a security association
> > > between the home agent and the mobile node.
> >
> > >
> > > >
> > > > What I want is to open up the possibility for the MN to go
> > > > through step 2-5 without neither having a home address nor
> > > > having been at home before:
> > >
> > > I don't think we can do this without changing the way RS's and
> > > RA's are sent. I think this issue is very important to resolve
> > > now because a change later to the method for sending RS's and
> > > RA's won't be upward compatible.
> >
> > Yes, I don't want to lock out such ideas in the draft. If we need to
> > finish this revision of the I-D urgently, we can go for this solution
> > right now. Later we have two options:
> > 1. fix it in future revisions of MIPv6... rev 17 or so... ;)
> > 2. put this in a draft that overrides MIPv6 in certain areas.
> > Then we will of course have backward compatibility problems.
> >
> > [...]
> >
> > > >
> > > > >  -  The Source Address in the packet's IPv6 header MUST be set
> > > > >     to the mobile node's primary care-of address.
> > > > >
> > > > >  -  The packet MUST be protected by IPsec [13, 11, 12] to guard
> > > > >     against malicious Router Solicitations.  The IPsec
> > protection
> > > > >     MUST provide sender authentication, data integrity
> > protection,
> > > > >     and replay protection, covering the Router Solicitation.
> > > > >
> > > > >  - The packet MUST include a Home Address destination option,
> > > > >    giving the mobile node's home address for its current
> > > > >    binding.
> > > > >
> > > > >  - The packet MUST include a Binding Update destination option
> > > > >    as described in section 10.6 if a current binding does not
> > > > >    yet exist. Otherwise, it MAY include a Binding Update
> > > > >    destination option.
> > > >
> > > > Here we have a problem. If the MN doesn't have a home address
> > > > it can't provide any at this point (step 3 above).
> > >
> > > Agreed. This is a problem for both the RS and RA. The way they
> > > are exchanged requires that the mobile node have at least one
> > > home address first. Some months back, I asked if it would be
> > > reasonable for the mobile node to generate a temporary address
> > > (very short lifetime) to get past this exchange. Such an
> > > address would only be allowed if it was based on a globally
> > > unique interface id.
> >
> > I don't see why the exact look of the address would matter.
>
> The global interface id restriction was based on the idea that
> the mobile node was generating and using the interface id from
> local information only without running DAD first. The real
> objective was to to ensure there was near zero chance of a
> duplicate address with another node. It doesn't really matter
> how this objective is met. This just seemed a simple way to
> do it.

Ok, I see.

>
> >
> > > > Is there a way we can leave this open for a lost MN with no
> > > > home address?
> > >
> > > The only way I could think of was to always tunnel the RA and
> > > RS per RFC 2473 instead of using the home address option
> > > and the routing header. I tried to think of ways to
> > > initialize using link-local addresses or the unspecified
> > > address for the mobile node, but doing so without a tunneled
> > > IPv6 header violated the base spec.
> > >
> >
> > I think we can always tunnel ourselves away from problems... :)
>
> Or into more more problems ;)
>
> >
> > > The problem with switching to RFC 2473 tunneling is that
> > > we would have to clearly define how to secure the message,
> > > how to associate a tunneled message to a specific binding,
> > > what to do if no binding exists, and how to attach a binding
> > > update/acknowledge option to a tunneled RS/RA.
> >
> > I would try to avoid BUs/BAs now.
>
> OK.
>
> >
> > >
> > >
> > > It seemed much simpler and less disruptive to the current
> > > spec to let the mobile node generate a temporary address.
> >
> > Ok, I see.
> >
> > >
> > >
> > > > However, we must still secure the protocol, of course, but we
> > > > can do this
> > > > without a home address.
> > > >
> > > > Are the Home Address Option and Binding Update really needed,
> > > > unless the HA is
> > > > expecting an ack?
> > >
> > > Hmm, I hadn't thought of this. If I understand you correctly,
> > > your suggesting the mobile node send the RS directly from
> > > its care-of address to the home agent with no home address
> > > option? I suppose it could work, but I'm not comfortable
> > > with it. This implies to me that the home agent returns
> > > the RA back to the mobile node's care-of address with no
> > > routing header. The home agent would normally put the mobile
> > > node's home address in the routing header, but the mobile
> > > node doesn't have a home address configured yet. This
> > > solution feels to me like exchanging RS's and RA's over one
> > > interface (with the care-of address) to configure another
> > > interface (with the home address).
> >
> > Correct! But the home address interface could under some
> > circumstances be
> > regarded as lying on top of other more physical interfaces where the
> > care-of addresses are. Isn't this exactly what happens during
> > tunneled RA
> > from HA to renumber the MN?
>
> Yes, but the existance of the tunnel header is an explicit
> signal that the intended destination is the home network
> pseudo interface insteaded of the care-of network
> physical interface. The current use of routing header
> and home address option do the same thing. I think we
> need some form of explicit marker that indicates which
> interface the RS/RA apply to.

Well... yes. You are right. Need to think about this.
>
> >
> > >
> > > Of the three options for handling RS's and RA's, my
> > > preference is:
> > >
> > >  1st: Keep the current mechanisms which require that the
> > >       mobile node somehow get an initial home prefix and
> > >       address before communication starts. Method to be
> > >       specified later.
> > >
> > >  2nd: Use RFC 2473 style tunneling.
> > >
> > >  last: Exchange RS's and RA's directly between a
> > >       the home agent and the mobile node's care-of
> > >       address to configure the mobile node's home
> > >       addresses.
> > >
> > > Ken
> >
> > So, I'd like to refine my proposed procedure once again:
> >
> > 1. MN somehow knows it's home prefix (manual, name, AAA & NAI, ...)
>
> Could you change this to "knows its home agent anycast address"?
>
> > 2. MN sends RS to HA
> >   2a. MN has to find an HA first by DHAAD.
> >   2b. For DHAAD MN needs to send ICMP HAAD Request to anycast address
> >   2c. One HA replies with Home Agents list.
> >   2d. MN picks one HA and tunnels an RS to it.
>
> Could you give DHAAD procedure and home agent selection as
> step two, then have separate step 3 for "MS sends RS..."?
>
> >         Outer src= care-of address
> >         Outer dst= HA's global address
> >         Inner src= whatever... CoA or LL maybe.
>
> Suggest using the "unspecified address" for the Inner src,
> same as if the node were on-link.
>
> >         Inner dst= ff02::x
> >         This packet doesn't need AH. I don't see this as a
> >         possible DoS threat.
> > 3. HA returns an RA. This message must not include a binding
> >     request (MN is polling).
> >     This packet must be covered by AH. An SA has to be set up
> >     between MN's CoA and the HA. How this is done is out of
> >     scope, but MN and HA have some shared secret
> >     or can be verified by someone.
>
> How does the RA get returned? I think this needs to specify
> using RFC 2473 style tunnel encapsulation instead of a routing
> header. The mobile node doesn't have a global home address yet.
> Would the following addresses make sense?
>
>           Outer src= HA's global address
>           Outer dst= care-of address
>           Outer src= HA's home subnet link-local address
>           Inner dst= all-nodes multicast address
>
> > 4. MN parses RA and configures all prefixes and addresses
> >     according to the method stated there.
> >   4a. If stateless is used: form Home address statelessly and
> >       let HA run DAD for it.
> >   4b. If stateful is used: talk to DHCPv6 server to receive
> >       an address. Currently, DHCPv6 is based on link- or
> >       site-local multicast. MN might have to tunnel the request
> >       and reply via the HA.
>
> I don't think we should assume anything about how statefull
> configuration is performed. How about say:
>
>      4b. If the the M or O flags are set in the router
>          advertisement, follow the statefull (DHCPv6)
>          configuration procedures.
>
> >   4c. If future methods are used: tunnel requests through home agent.
>
> I don't see any reason to restrict future configuration methods
> to always working through the home agent. I'm assuming your
> describing requests of some as yet undefined protocol.

That's right.

>
> > 5. MN registers with HA by sending BUs for all Home Addresses.
> >    This time a new SA is set up between MN and HA. HA checks DAD
> >    if needed.
> >
> > Summary: we don't need a parallel address configuration
> > method for mobile nodes. A mobile node will be configured
> > exactly as if it was at home.
>
> Looks like we are headed for parallel ways to send RA/RS
> to avoid a parallel home address configuration method.
> I'm not at all happy with doing that. I would rather see
> us adopt a single consistent method for exchanging RS/RA.
> If we have to change how RS/RA are sent, lets do it the
> right way now.
>
> Ken

I could go with the Appendix solution at the moment.

/Mattias


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 08:37:55 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24597
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 08:37:54 -0500 (EST)
Received: from standards (47.234.32.16:3532) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB397B@standards.nortelnetworks.com>; Fri, 10 Nov 2000 8:19:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 95671 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 08:19:40
          -0500
Received: from ztxmail05.ztx.compaq.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB3979@standards.nortelnetworks.com>; Fri, 10 Nov 2000 8:19:36
          -0500
Received: by ztxmail05.ztx.compaq.com (Postfix,
          from userid 12345) id 78C4E1725; Fri, 10 Nov 2000 07:35:55 -0600 (CST)
Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net
          [16.103.129.53]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id
          3BCBE1640; Fri, 10 Nov 2000 07:35:55 -0600 (CST)
Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service
          (5.5.2650.21) id <WSTJNG11>; Fri, 10 Nov 2000 08:35:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Powell, Ken" <Ken.Powell@COMPAQ.COM>
Message-ID:  <C99A689B0CB9D111AF3F0000F8062CCD08FB83C3@zkoexc2.zko.dec.com>
Date:         Fri, 10 Nov 2000 08:35:39 -0500
Reply-To: "Powell, Ken" <Ken.Powell@compaq.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Powell, Ken" <Ken.Powell@compaq.com>
Subject:      Re: [MOBILE-IP] Binding Cache entries per IPv6 address at Corresp
              ondent  Node
X-To:         Mattias Pettersson <mattias.pettersson@era.ericsson.se>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> -----Original Message-----
> From: Mattias Pettersson [mailto:mattias.pettersson@era.ericsson.se]
> Sent: Friday, November 10, 2000 4:32 AM
> To: Powell, Ken
> Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] Binding Cache entries per IPv6 address at
> Correspondent Node
>
>
> "Powell, Ken" wrote:
> >
> > I'm not sure how the clause "for each of its IPv6 addresses"
> > applies when the prefix length is non-zero. In this case, a
> > single binding covers multiple addresses.
>
> It's the CN/HA that keeps a BC for each of its _own_
> addresses. Not one
> for every address the MN has. Or do I misunderstand you?
>

You understood me correctly, and this is exactly what I
was confused about yesterday. Thanks for clarifying it.

Ken


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 09:37:14 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19349
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 09:37:13 -0500 (EST)
Received: from standards (47.234.32.16:3532) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB3A0E@standards.nortelnetworks.com>; Fri, 10 Nov 2000 9:18:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 95873 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 09:18:54
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:42732) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB3A0C@standards.nortelnetworks.com>; Fri, 10 Nov 2000
          9:18:53 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id BAA02964 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sat, 11 Nov 2000 01:31:53
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id BAA18074 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sat, 11 Nov 2000 01:34:37
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBDP231>; Sat, 11 Nov 2000 01:34:50 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613DD4@eaubrnt018.epa.ericsson.se>
Date:         Sat, 11 Nov 2000 01:34:50 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] Binding Cache entries per IPv6 address at Corresp
              ondent Node
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> Richard Draves wrote:
> >
> > >  Binding Cache
> > >
> > >          A cache, maintained by each IPv6 node, of bindings for other
> > >          nodes.  A separate Binding Cache SHOULD be maintained by each
> > >          IPv6 node for each of its IPv6 addresses.
> >
> > This is an interesting problem! First let me confirm: my understanding
> is
> > that a MN can only have a single mapping from HA to CoA, because it can
> send
> > its home agent a single such binding. In particular, a MN can not
> reasonably
> > use one CoA when talking to one correspondent and a different CoA when
> > talking to a different correspondent.
>
> Indeed it can. I think that it is a likely case, although very advanced.
> There would be a point in registering different CoAs with different CNs,
> depending on e.g. where you'd want your traffic to flow. In the
> extension, there could be a need to not only register a binding for a
> home address, but also for a port number.
>
        => Yes I agree, draft-ietf-mobileip-hmipv6-  is a good
        example for the case Mattias mentions where the MN registers
        different COA's with different CNs


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 11:59:57 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08380
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 11:59:56 -0500 (EST)
Received: from standards (47.234.32.16:2621) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB3AFA@standards.nortelnetworks.com>; Fri, 10 Nov 2000 11:41:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 96181 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 11:41:36
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB3AF8@standards.nortelnetworks.com>; Fri, 10 Nov 2000 11:41:36
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAAGvZb18769; Fri, 10 Nov 2000 17:57:36 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr
          [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with
          ESMTP id RAA16426; Fri, 10 Nov 2000 17:57:34 +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.9.3/8.9.3) with
          ESMTP id RAA61266; Fri, 10 Nov 2000 17:59:16 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011101659.RAA61266@givry.rennes.enst-bretagne.fr>
Date:         Fri, 10 Nov 2000 17:59:16 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Charlie Perkins <charliep@iprg.nokia.com>
X-cc:         Richard Draves <richdr@microsoft.com>,
              Francis Dupont <Francis.Dupont@inria.fr>,
              Vijay Devarapalli <vijayd@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Thu, 09 Nov 2000 04:44:55 PST. 
              <3A0A9C47.A9DD5107@iprg.nokia.com>

 In your previous mail you wrote:

   I'm trying to follow up on some discussion a few days ago
   about this point.  The last indication I received was that a
   node receiving a packet with an ESP header should be
   able to decrypt the payload using only the SPI and the
   destination IPv6 address.  I had always thought that the
   receiving node would want to use the mobile node's home
   address to select the correct security association.  Recent
   messages indicate that other implementations do not use
   that information; then they presumably do not use the
   IPv6 source address at all when identifying the correct
   security association.

   This is a crucial point, and a decision should be made ASAP.

=> the current IPsec spec (RFC 2401) is not very clear but:
 - the source address should not be used by the lookup of the SA
 - the source address should be used by post-processing checks
I have looked at 4 free implementations:
 - all of them don't use the source address for the SA lookup
 - two of them do the check of the source address at the end of
   the SA lookup then the source address must be available (ie.
   the header with the home address option must be before the first
   IPsec header)
 - only one of them don't check the source address after the processing
   of a IPsec header in transport mode
Conclusion: if the home address is not available after the processing
of *each* IPsec header then we'll kill near all IPsec implementations
(ie. someone will say we'll kill all compliant implementations), if
it is not available before any IPsec header then we'll kill all paranoic
implementations (at least one half IMHO).

   There seem to be two additional relevant points:

   - We should pick a placement for the Home Address option,
      and make it mandatory.  Doing so will simplify the implementation
      for all the billions of correspondent nodes of the future.  We want
      that implementation to be as simple as possible.  The two
      candidate placements are either after ESP, possibly in the
      same options header as the Binding Update, or else before
      the Fragment Header.

=> I agree. According to RFC 2401 section 5.2.1 (1) and (2) the placement
after ESP is not possible then only the placement before the fragment
header doesn't badly interfere with (mandatory) IPsec.

   - Putting the information after ESP will make things substantially
      more complicated for possible firewall management.

=> simply doesn't work: if you have AH then ESP, AH is mandatory and
this order is the preferred one for many reasons (it is enough that
it is a legal order BTW) then the AH processing will fail at the (2)
(selector check) of RFC 2401 (*).

   Based on this evidence, I am leaning towards a mandatory placement
   before the Fragment Header.  As soon as I can determine consensus
   on this point, I am ready to issue a revised (and hopefully last)
   Internet Draft for Mobile IPv6.

=> I think this placement is the best one and I agree this should be
mandatory.

Thanks

Francis.Dupont@enst-bretagne.fr

* PS: RFC 2401 Section 5.2.1:

   ... Note that the
   selector checks are made on the inner headers not the outer (tunnel)
   headers.  The steps followed are:

           1. Use the packet's destination address (outer IP header),
              IPsec protocol, and SPI to look up the SA in the SAD.  If
              the SA lookup fails, drop the packet and log/report the
              error.

           2. Use the SA found in (1) to do the IPsec processing, e.g.,
              authenticate and decrypt.  This step includes matching the
              packet's (Inner Header if tunneled) selectors to the
              selectors in the SA.  Local policy determines the
              specificity of the SA selectors (single value, list,
              range, wildcard).  In general, a packet's source address
              MUST match the SA selector value.
              ...

              Do (1) and (2) for every IPsec header until a Transport
              Protocol Header or an IP header that is NOT for this
              system is encountered.

(the last statement is very important for the AH then ESP sequence).


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 12:27:56 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18039
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 12:27:55 -0500 (EST)
Received: from standards (47.234.32.16:2621) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB3B58@standards.nortelnetworks.com>; Fri, 10 Nov 2000 12:09:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 96306 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 12:09:44
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB3B56@standards.nortelnetworks.com>; Fri, 10 Nov 2000 12:09:43
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAAHPnb15831; Fri, 10 Nov 2000 18:25:49 +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 SAA17252; Fri, 10 Nov 2000 18:25:47 +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.9.3/8.9.3) with
          ESMTP id SAA61498; Fri, 10 Nov 2000 18:27:30 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011101727.SAA61498@givry.rennes.enst-bretagne.fr>
Date:         Fri, 10 Nov 2000 18:27:30 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> CC field duplicated. Last occurrence was
              retained.
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] Placement for Binding Update and Home Address
              options
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
X-cc:         ipng@sunroof.eng.sun.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Thu, 09 Nov 2000 10:14:35 PST. 
              <3A0AE98B.46A6DD3E@iprg.nokia.com>

 In your previous mail you wrote:

   Bottom line _proposal_:

   Mandatory placements:
           - Home Address option between Routing and Fragment Headers
           - Binding Update after ESP.

=> I agree, home address and tunnel encapsulation limit between routing
and fragment, all other destination options (binding XXX) after ESP.

   Comments?

=> this makes three placements for a destination option header, two
were already too many. The whole destination option header concept
should be redone, for instance my proposal is:
 - kill the placement between hop-by-hop and routing headers
   (not used, just make implementations more complex)
 - keep the placement between routing and fragment headers for type 60
 - get a new type from IANA for placement after ESP (IPCOMP in fact)
This will give in the future simplest/cleanest implementations, the price
is incompatibility for mobile IPv6 implementations (which should be
incompatible in some cases with any proposal :-).

Thanks

Francis.Dupont@enst-bretagne.fr

PS: I have added the IPng WG mailing list because this is in its scope.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 13:51:16 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20149
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 13:51:16 -0500 (EST)
Received: from standards (47.234.32.16:3355) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB3C11@standards.nortelnetworks.com>; Fri, 10 Nov 2000 13:32:56 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 96565 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 13:32:56
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBB3C0F@standards.nortelnetworks.com>;
          Fri, 10 Nov 2000 13:32:55 -0500
Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id LAA29023; Fri, 10 Nov 2000 11:49:14
          -0700 (MST)
Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by
          engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          KAA29248; Fri, 10 Nov 2000 10:49:11 -0800 (PST)
Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id
          eAAIm5F16514; Fri, 10 Nov 2000 10:48:05 -0800 (PST)
X-Sun-Charset: US-ASCII
Approved-By:  Mohan Parthasarathy <Mohan.Parthasarathy@ENG.SUN.COM>
Message-ID:  <200011101848.eAAIm5F16514@locked.eng.sun.com>
Date:         Fri, 10 Nov 2000 10:48:05 -0800
Reply-To: Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         richdr@microsoft.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

 >
> > > - Putting the information after ESP will make things substantially
> > >    more complicated for possible firewall management.
> >
> > ESP might make firewall management more complicated, I won't
> > dispute that. But my point is that users & admins should have
> > a choice of using AH or ESP. In some environments, the
> > appropriate choice might be ESP. In other environments, AH
> > might be an appropriate choice.
> >
> > If the Home Address option follows an AH header, a firewall
> > can still find it easily. So if you want to be friendly to
> > firewalls, have a policy of using AH. But please don't
> > prevent others from using ESP.
>
> Aha, I just got why you want the Home Address before a Fragment header for
> firewalls: so they can see the Home Address in every packet even fragments.
> Duh. And the Fragment header has to be before the IPsec headers. Since ESP
> isn't friendly to firewalls anyway, firewall-friendliness is only a concern
> for AH. This means two header orders make sense:
> a) IPv6, Home Address, possible Fragment, AH, Binding Update, Transport
> b) IPv6, possible Fragment, ESP (auth and/or encryption), Home Address &
> Binding Update with CoA suboption, Transport
>
Home Address option - a destination option can appear anywhere
and it is not really a destination option anymore :-) Does this
mean RFC2460 needs an update where the recommended order makes
no more sense (Tunnel encapsualtion limit already broke this
some time back).

-mohan


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 15:22:37 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21847
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 15:22:37 -0500 (EST)
Received: from standards (47.234.32.16:2571) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB3CA2@standards.nortelnetworks.com>; Fri, 10 Nov 2000 15:01:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 96760 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 15:01:25
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB3CA0@standards.nortelnetworks.com>; Fri, 10 Nov 2000 15:01:25
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Fri, 10 Nov 2000 12:17:00 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <W4S4WKBQ>; Fri, 10 Nov 2000 12:17:43 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA80130C900@red-msg-06.redmond.corp.microsoft.com>
Date:         Fri, 10 Nov 2000 12:17:27 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] Binding Cache entries per IPv6 address at Corresp
              ondent Node
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> > > This is an interesting problem! First let me confirm: my
> understanding
> > is
> > > that a MN can only have a single mapping from HA to CoA,
> because it can
> > send
> > > its home agent a single such binding. In particular, a MN can not
> > reasonably
> > > use one CoA when talking to one correspondent and a
> different CoA when
> > > talking to a different correspondent.
> >
> > Indeed it can. I think that it is a likely case, although
> very advanced.
> > There would be a point in registering different CoAs with
> different CNs,
> > depending on e.g. where you'd want your traffic to flow. In the
> > extension, there could be a need to not only register a
> binding for a
> > home address, but also for a port number.
> >
>         => Yes I agree, draft-ietf-mobileip-hmipv6-  is a good
>         example for the case Mattias mentions where the MN registers
>         different COA's with different CNs

So the mobile node can register a single "primary" HA -> CoA mapping with
its home agent, but then after that it can give different correspondents
different mappings?
OK.

Rich


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 15:42:22 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28349
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 15:42:21 -0500 (EST)
Received: from standards (47.234.32.16:2571) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB3D18@standards.nortelnetworks.com>; Fri, 10 Nov 2000 15:24:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 96919 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 15:24:04
          -0500
Received: from cisco.com (omega.cisco.com) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBB3D16@standards.nortelnetworks.com>; Fri, 10 Nov 2000 15:24:04
          -0500
Received: from gopal.cisco.com (dhcp-171-70-57-76.cisco.com [171.70.57.76]) by
          cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA12872;
          Fri, 10 Nov 2000 12:40:22 -0800 (PST)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
References: <3.0.32.20001020175404.00e8470c@era-t.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Approved-By:  Gopal Dommety <gdommety@CISCO.COM>
Message-ID:  <4.3.2.7.2.20001110122714.00da8e70@omega.cisco.com>
Date:         Fri, 10 Nov 2000 12:37:16 -0800
Reply-To: Gopal Dommety <gdommety@cisco.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gopal Dommety <gdommety@cisco.com>
Subject:      Re: [MOBILE-IP] WG Last Call
              -(draft-ietf-mobileip-reg-tunnel-03.txt)
X-To:         Satwant Kaur <wizkid11@XNET.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <004d01c03b11$82ec9740$878bf3cd@piii>

At 10:46 PM 20/10/00 -0500, Satwant Kaur wrote:
>Hello,
>
>I am implementing the Regional Registration
>(draft-ietf-mobileip-reg-tunnel-03.txt), and I agree with Annika that it is
>important for FA and GFA to be able to make the distinction between the Home
>Registration Request (type 1) and Regional Registration Request (type 2)
>messages. Furthermore, the mobility Agents should also be able to make a
>distinction between Registration Reply (type 3) and Regional registration
>reply (type 4).


You will be able to distinguish between a the two type of registrations (I would like to
call regional registration a special case of registration) based on the persence or absence
of the new extension (call it regional extension). The same will apply to the registration reply.
To clarify the case when you are performing a regional registration the registration will have this
extension (this extension can be of critical type).

The reason one should use an extension  and not a new type is because:

1. Regional registration is a special case of registration and the solution is not to create a new type for
every special case.

2. One does not have to reinvent everything  (such as extensions ) for this new registration ( even if we
ignore the simplicity of developing this feature on the mobiles and agent using the existing code base).

-Gopal




Thanks
Gopal


>Another case where a similar problem would arise:
>
>Suppose MN wants to do Home Registration with a FA who does not advertise
>itself. MN wants to be assigned a GFA and so it sends a Home Registration
>Request (type 1) with careof field as 0, and HA address in the Home Agent
>field.
>
>Now, if we do not have additional message types to be able to make a
>distinction between type 1 and type 2 Registration requests, the FA will
>have no way of knowing if (1) It is a home Registration with MN asking to be
>assigned a GFA for home Registration, or (2) It is a Regional Registration
>(with FA set to 0, since FA did not advertise itself).
>
>FA can (mis)interpret it as type 2 message. It will incorrectly assume that
>the HA address is really the GFA that the MN wants to register with. It will
>then forward the request to its HA address under the assumption it is really
>the GFA, instead of assigning a GFA address, and forwarding the registration
>to the assigned GFA.
>
>The above problem arose since FA reads the registration requests sent by MN,
>and forwards them to GFA. In the absence of the message type that would
>enable FA to make a distinction between home registration request (type 1)
>and regional registration request (type 2), the FA does not know where to
>send the request to. The GFA address lies in the Home Agent field in case of
>type 2 and in the careof field in case of type 1 message. If the additional
>type 2 message is not there, FA cannot make the distinction between Home Vs
>Regional Registration Request.
>
>Similar problems will arise at GFA level, since when the GFA reads the
>Registration Requests sent out by FA, and either forwards them to HA (in
>case of Home Registration) or sends the reply back to FA (in case of
>Regional Registration). If the type 2 message type is not there, GFA cannot
>make the distinction between Home and Regional Registration. And it would
>not know whether to send it forward to HA, or to send reply back to FA.
>
>Similar problems will also arise on the way back for Registration Reply
>messages at FA and GFA, if type 4 is not present.
>
>Apart from the problems in the above special cases, I also do not favor
>using anything other than message types to understand what type of
>registration /registration reply it is. The reason is if one uses some other
>characteristics of the packets (in this case, the extensions) other than its
>"type" to identify the type of packets, it is against the spirit of
>assigning the right job to the right field. It may also give us grief down
>the road as it would restrict our freedom to use extensions in different and
>more creative ways in future.
>
>----- Original Message -----
>From: "Annika Jonsson" <annika.jonsson@ERICSSON.COM>
>To: <MOBILE-IP@standards.nortelnetworks.com>
>Sent: Friday, October 20, 2000 10:54 AM
>Subject: Re: [MOBILE-IP] WG Last
>Call -(draft-ietf-mobileip-reg-tunnel-03.txt)
>
>
>> Hi Gopal,
>>
>> as Charlie say's, we have discussed this a lot. Here are some of our
>> reasoning. The home and the regional registrations will always differ
>> because of different replay protection and security associations for the
>> authentication extensions. Furthermore, the FA has to be able to handle
>> many different cases: a) normal RFC2002 registration b) home registration
>> through GFA (to prepare for regional registrations) c) home registration
>> with GFA set to zero (to ask that a GFA be assigned) d)regional
>> registration e) regional registration with FA set to zero (in case FA does
>> not advertise itself).
>>
>> Therefore we think that using different message types to separate the
>> handling of the home and the regional registration messages would make it
>> simpler for the FA:s. I can give you one example: The MN is allowed to try
>> to do a regional registration to the GFA it has been using, even though
>> that GFA is not advertised by the new FA. In this case, if the FA does not
>> know this GFA it must send back an error to the MN. If the FA didn't know
>> that this was a regional registration, it would assume that the old GFA is
>> the MN:s HA, and that this was a normal RFC2002 registration, and the
>> registration would fail.
>>
>> /Annika
>>
>> At 22:35 2000-10-11 -0700, Gopal Dommety wrote:
>> >Charlie,
>> >
>> >
>> >1.  If you can perform a global registration via the hierarchy with out
>> requiring new messages, it is
>> >possible to do regional reg without introducing the new messages.
>> >
>> >2. The difference between the reg and global registration should be where
>> the registration finally gets processed and reg reply is generated (i.e,
>in
>> one case the it goes through the GFA to the HA and gets processed there,
>in
>> the regional case
>> >it is processed by the common GFA between the old and the new paths - if
>> more than two levels of hierarchy is employed)..
>> >
>> >3. The reasons you have given in the Appendix for introducing new
>messages
>> are given below:
>> >
>> >                -  a mobile node must be able to distinguish
>> >                            between regional registrations and home
>> >                            registrations, because when it uses
>> >                            regional registration, the nounces are not
>> >                            synchronized with its home agent;
>> >
>> >                         -  a mobile node can use a zero care-of
>> >                            address either to request a GFA (in a home
>> >                            registration) or to signify the use of an
>> >                            unspecified regional foreign agent (in a
>> >                            regional registration).
>> >
>> >Both these can be equally easily handled with the extensions approach.
>> >
>> >more comments below:
>> >
>> >
>> >>> 1. What is the fundamental reason for introducing  new  regional
>> registration request/reply messages. I think
>> >>> this is unnecessary introduction of new message types.
>> >>
>> >>We puzzled over this for quite a while, more than one time.
>> >>There is discussion about the reasons for the change in
>> >>Appendix A. We think that processing is very much more
>> >>natural for the case when there are separate message types,
>> >>instead of extensions to the existing messages.  Clearly,
>> >>making extensions to the existing messages would have
>> >>the effect of introducing a lot of additional case analysis
>> >>into existing code for handling RFC 2002 registration
>> >
>> >Could you give concrete examples of the cases that cannot be handled by
>> >an extension.
>> >
>> >
>> >>messages.  There are other reasons, as mentioned in the
>> >>draft appendix, related to allowing for non-disclosure of
>> >>foreign agent hierarchies.  This is especially true for multiple
>> >>levels of hierarchy.
>> >
>> >don't see why multiple hierarchies is a problem.
>> >
>> >moreover, if we are employing multiple hierarchies, if will apply to the
>> home registration also.
>> >
>> >
>> >>>  a) You are using extensions for the initial registration through the
>> GFA. You could as well use the extensions for achieving regional
>> >>> registrations.
>> >>
>> >>That is different, because the initial registration _is_ a home
>> registration.
>> >
>> >It should not be, other than the fact who is supposed to processes the
>> message and the extensions.
>> >
>> >
>> >>> b) In fact your version 02 of the draft
>> (draft-ietf-mobileip-reg-tunnel-02.txt) does not have these new messages.
>> >>
>> >>We couldn't make it work very well that way in all cases, as I've
>alluded
>> to already.
>> >>
>> >>> Unless there is a good reason, I think you should use extensions.
>Using
>> existing messages with extensions makes
>> >>> implementation easier and cleaner (we have seen that in implementing
>> anchor handoff draft draft-dommety-mobileip-anchor-handoff-02.txt).
>> >>
>> >>On the contrary, I really think that using new messages makes the
>> implementation
>> >>easier and cleaner, exactly because then the implementation does not
>have
>> to build
>> >>up as much global state and case analysis.  Furthermore, as I have
>> mentioned already,
>> >>there are cases that cannot be handled as easily with extensions.  I
>> think that the
>> >
>> >could you provide concrete examples of what cases cannot be handeled?
>> >
>> >
>> >Regards,
>> >Gopal
>> >
>>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 15:49:04 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00558
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 15:49:04 -0500 (EST)
Received: from standards (47.234.32.16:2571) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB3D59@standards.nortelnetworks.com>; Fri, 10 Nov 2000 15:28:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 97002 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 15:28:57
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB3D57@standards.nortelnetworks.com>; Fri, 10 Nov 2000 15:28:57
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Fri, 10 Nov 2000 12:11:40 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <W4S4WJDN>; Fri, 10 Nov 2000 12:12:23 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA80130C8FE@red-msg-06.redmond.corp.microsoft.com>
Date:         Fri, 10 Nov 2000 12:09:16 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Francis Dupont <Francis.Dupont@enst-bretagne.fr>,
              Charlie Perkins <charliep@iprg.nokia.com>
X-cc:         Francis Dupont <Francis.Dupont@inria.fr>,
              Vijay Devarapalli <vijayd@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> I have looked at 4 free implementations:
>  - all of them don't use the source address for the SA lookup
>  - two of them do the check of the source address at the end of
>    the SA lookup then the source address must be available (ie.
>    the header with the home address option must be before the first
>    IPsec header)
>  - only one of them don't check the source address after the
> processing
>    of a IPsec header in transport mode
> Conclusion: if the home address is not available after the processing
> of *each* IPsec header then we'll kill near all IPsec implementations
> (ie. someone will say we'll kill all compliant implementations), if
> it is not available before any IPsec header then we'll kill
> all paranoic
> implementations (at least one half IMHO).

There are implementations for which this conclusion is not true.

I think the best approach is to figure out what is the right thing for the
protocol, and then implementors should implement it. Your approach seems to
be to look at what a few particular implementations do and then base the
protocol on that. Seems backwards.

Rich


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 17:27:38 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02402
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 17:27:37 -0500 (EST)
Received: from standards (47.234.32.16:1760) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB3E32@standards.nortelnetworks.com>; Fri, 10 Nov 2000 17:09:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 97293 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 17:09:03
          -0500
Received: from ztxmail05.ztx.compaq.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB3E30@standards.nortelnetworks.com>; Fri, 10 Nov 2000 17:09:02
          -0500
Received: by ztxmail05.ztx.compaq.com (Postfix,
          from userid 12345) id 14DA01780; Fri, 10 Nov 2000 16:25:23 -0600 (CST)
Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net
          [16.103.129.53]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id
          B262E15DD; Fri, 10 Nov 2000 16:25:22 -0600 (CST)
Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service
          (5.5.2650.21) id <WSTJ3QKT>; Fri, 10 Nov 2000 17:25:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Powell, Ken" <Ken.Powell@COMPAQ.COM>
Message-ID:  <C99A689B0CB9D111AF3F0000F8062CCD08FB83C6@zkoexc2.zko.dec.com>
Date:         Fri, 10 Nov 2000 17:25:18 -0500
Reply-To: "Powell, Ken" <Ken.Powell@compaq.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Powell, Ken" <Ken.Powell@compaq.com>
Subject:      Re: [MOBILE-IP] Appendix
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>,
              Mattias Pettersson <mattias.pettersson@era.ericsson.se>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Charlie,

I must have miscommunicated something here. The
text you proposed for appendix A has elements of
two conflicting approaches to solve the problem
of needing a global home address to generate a
global home address:

  A) The initial text for generating a temporary home
     address is only needed if we use the current
     technique of exchanging the router solicits
     and router advertisements.

  B) Steps 5 and 6 show how to send router solicitations
     and router advertisements using tunnels in a way
     that does not need the initial home address.

If we do B, we don't need to do A.

I have some big problems with B still. It was just
a quick proposal to give a vague idea how we could
meet Mattias's objectives. It does this by redefining
how router solicitations and router advertisements
are tunneled. This seriously impacts many sections
throughout the spec and needs to be fully defined
if we are going to use it.

Last night, I decided to run through the exercise of
finding the spec changes to support option B. I had a
gut feeling it was going to be difficult, and it
was. I'm including what I have so far with comments
sliced in showing the outstanding issues and giving
possible approaches to further changes. This is not
complete.

I think we should drop tunneling (option B) and return
to the original proposal for appendix A. I went back
to see how we stand with Mattias's key objectives by
doing this.

>> I would like the option to let the MN configure it's
>> home address as if it was at home, even if it is not
>> at home.

In approach A, the initial steps that generate a
temporary home address during the bootstrap phase
is the only part that is different. It does revert
to the same methods and results as if the mobile
node were physically at home once we get over the
bootstrap phase. The initial temporary address gets
deleted through the time-out mechanism if it does
not get updated through stateless address
autoconfiguration or DHCPv6.

>> What I want is to open up the possibility for the MN
>> to go through step 2-5 without neither having a home
>> address nor having been at home before.

The mobile node does not have to be preconfigured with
any global address. It just needs a globally unique
interface id.

>> Summary: we don't need a parallel address configuration
>> method for mobile nodes. A mobile node will be configured
>> exactly as if it was at home.

This is the piece we can't satisfy with option A, but can
with option B. Option A requires the additional address
configuration method to bootstrap communications.

Here are the detailed changes I came up with so far to
support option B. Side comments are bounded with "<>".
Are these changes really worth pursuing? Its going to
take much more effort to scrub it properly.

If we are going to adopt option B, we should do it now
because it is not backward compatible.

On page 70, replace the tunneling technique with:
=================================================

   In tunneling each such Router Advertisement to the mobile node, the
   home agent MUST construct the packet using IPv6 encapsulation [4] as
   follows:

    -  The tunnel entry point is the home agent's IP address to
       which the mobile node addressed its current home
       registration. If the router advertisement is being sent
       in response to a router solicitation from a node with no
       current home registration, the tunnel entry point is set
       to the exit point of the tunnel thru which the original
       router solicitation was received.

    -  The tunnel exit point is the primary care-of address. If the
       router advertisement is being sent in response to a router
       solicitation from a node with no current home registration,
       the tunnel exit point is set to the entry point of the tunnel
       thru which the original router solicitation was received.

       < I think its possible to do this, but I suspect it will
         require serious changes to existing stacks to carry the
         tunnel source and destination address up and down the
         stack with decapsulated packets. A possible way to avoid
         tunnel implementation issues is to support bindings
         on the home agent for the mobile node's link local
         address. Once done, the kernel could use much the
         same mechanisms to route RA/RS with link local addresses
         as it would use for routing the mobile node's global
         home addresses. This of course would require another
         whole series of changes to the spec. >

    -  The Source Address of the inner IPv6 header is set to the
       home agents link-local IP address on the home network.

    -  The Destination Address of the inner IPv6 header is set to
       the mobile node's home subnet link-local address.

       < I first intended to use the all-nodes multicast address,
         but didn't know if IPsec works well with multicast
         addresses. >

    -  The inner IPv6 header must be protected by IPsec [13, 11, 12]
       to guard against malicious Router Advertisements.  The IPsec
       protection MUST provide sender authentication, data integrity
       protection, and replay protection, covering the Router
       Advertisement.

       < I initially considered putting this in the tunnel header,
         but most tunneled packets from the home agent to the mobile
         node don't require IPsec, so this would probably require
         special logic in the tunnel code to handle. I expect
         applying IPsec to the inner header would be easier and
         will still achieve the intended security. >

    -  The packet MUST include a Binding Request destination option
       after the IPsec Authorization or Encapsulation header.

       < Putting the Binding Request here allows the mobile node
         to strip off the outer IPv6 headers the same as it would
         do for any other tunneled message. >

    -  The Binding Request destination option MUST include a Unique
       Identifier Sub-Option (Section 5.5), with the unique identifier
       in the sub-option data set to a value different than that in
       any other Binding Request sent recently by this node.  The word
       "recently" here means within the maximum likely lifetime of a
       packet, including transit time from source to destination and
       time spent awaiting reassembly with other fragments of the same
       packet, if fragmented.  However, it is not required that a source
       node know the maximum packet lifetime.  Rather, it is assumed
       that the requirement can be met by maintaining a simple 16-bit
       "wrap-around" counter to generate unique identifiers for Binding
       Requests that contain a Unique Identifier Sub-Option, incremented
       each time a Binding Request containing a Unique Identifier
       Sub-Option is sent.

       < Its going to be difficult to track the status of this
         binding request when the mobile node has no home address
         and has not yet created a binding. Once again, creating a
         binding for the mobile node's link-local address would help. >


On page 92, replace the rules for validating
received router advertisements on the mobile node:
==================================================

   When a mobile node receives a tunneled Router Advertisement, it MUST
   validate it according to the following tests:

    -  The Router Advertisement was received over a tunnel whose
       entry point was the same as the home agent address to which the
       mobile node last sent an accepted "home registration" Binding
       Update to register its primary care-of address. If no home
       registration exists yet, the tunnel entry point must be the
       same as the exist point of a tunnel through which a
       Router Solicitation was recently transmitted.

    -  The inner IPv6 packet MUST be protected by IPsec [13, 11, 12]
       to guard against malicious Router Advertisements.  The IPsec
       protection MUST provide sender authentication, data integrity
       protection, and replay protection, covering the Router
       Advertisement.

    -  The inner packet contains a Binding Request destination option.

    -  The Binding Request option contains a Unique Identifier
       Sub-Option.


Modify my previous proposal for sending Router
Solicits from the mobile node to the home agent:
================================================

The mobile node must construct and tunnel such a Router Solicitation
packet using IPv6 encapsulation [4] as follows:

 -  The tunnel entry point is the mobile node's primary care-of
    address.

 -  The tunnel destination is the home agent's global IP address.

 -  The Source Address of the inner IPv6 header is set to the
    unspecified IP address (0::0).

 -  The Destination Address of the inner IPv6 header is set to
    the all routers multicast address.

 -  The tunnel header MUST be protected by IPsec [13, 11, 12] to guard
    against malicious Router Solicitations.  The IPsec protection
    MUST provide sender authentication, data integrity protection,
    and replay protection, covering the Router Solicitation.

    < I think we should keep this requirement if responding to
      unauthorized probes for address information could be a bad
      thing at some sites. >

    < If we decide link-layer address bindings are a good thing,
      we could send a binding update in the inner IP packet
      for the link-layer address, and specify an Alternate Care-Of
      suboption containing the mobile node's primary care-of
      address. >

 - The Router Solicitation's source link-layer address
   option MUST be omitted.

    < We may wish to change this given home subnet link layer
      address in the inner IP header and a possibility of a
      binding for the link layer address. >


Modify my previous proposal for how the Home Agent
receives Router Solicitations from Mobile Nodes
=================================================

The Router Solicitation may include a Binding Update
destination option. The processing requirements described
here for the Router Solicitation assume the Binding Update
destination option was processed first. The home agent MAY
return a single packet containing both the resulting Binding
Acknowledgment destination option and a Router Advertisement.

 < Remove paragraph on how to handle binding
   updates included with the router solicitation
   unless we implement bindings for a link-layer
   addresses >

When a home agent receives a tunneled Router Solicitation from
a mobile node on a remote network, it MUST validate it according
to the following tests:

 - The inner packet is protected by IPsec [13, 11, 12] to guard
   against unauthorized probes for home subnet information.  The
   IPsec protection provides sender authentication, data integrity
   protection, and replay protection, covering the Router
   Solicitation.

    < All the other tests are unnecessary with tunnels
      unless we implement bindings for link-local
      addresses. >


> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Thursday, November 09, 2000 4:38 PM
> To: Mattias Pettersson; Powell, Ken
> Cc: Mobile IP Mailing List
> Subject: Appendix
>
>
>
> Hello folks,
>
> Here is a stab at an appendix.  It needs proofreading, but
> I have to go for now and I thought it would be better to
> send something defective for now and touch it up more later.
>
> My opinion is that a Binding Update is needed, and if it takes
> another few hundred milliseconds, that's O.K.  So, I retained
> that step for the part after the Router Advertisement was
> received by the mobile node.  However, this is of course up
> for discussion.
>
> I reckon the hard part will be to manage the identification
> for the mobile node.  As Hesham mentions, NAI could be used
> for this.  However, I am sure that everyone agrees that right
> now is not the time for trying to complete that discussion.
>
> Regards,
> Charlie P.
>
> =====================================================================
>
>
> A. Remote Home Address Configuration
>
>    The method for initializing a mobile node's home addresses on
>    power-up or after an extended period of being disconnected from
>    the network is beyond the scope of this specification.  Whatever
>    procedure is used should result in the mobile node having the same
>    stateless or stateful (e.g., DHCPv6) home address autoconfiguration
>    information it would have if it were attached to the home network.
>    Due to the possibility that the home network could be renumbered
>    while the mobile node is disconnected, a robust mobile
> node would not
>    rely solely on storing these addresses locally.
>
>    A mobile node MAY generate a temporary home address using the
>    following information:
>
>     -  the subnet prefix from the home network's mobile agent anycast
>        address, and
>
>     -  the globally unique interface identifier that would have been
>        used to generate the link local address if the mobile node were
>        attached directly to the home network.
>
>    Such a temporary address could be used to establish a binding with
>    a home agent in the absence of any other known home addresses.  It
>    could be created with short valid lifetime and a preferred lifetime
>    of zero to ensure a quick transition to other addresses generated
>    when stateless or stateful (DHCPv6) address autoconfiguration runs.
>
>    Such a mobile node could initialize by using the following
> procedure:
>
>     1. Query DNS for the home network's mobile agent anycast address.
>
>     2. Generate a care-of address using stateless or stateful
>        autoconfiguration.
>
>     3. Send a Home Agent Address Discovery Request message to the home
>        network.
>
>     4. Receive Home Agent Address Discovery Reply message.
>
>     5. MN picks one Home Agent and tunnels an Router
> Solicitation to it.
>
>           Outer src = care-of address
>           Outer dst = Home Agent's global address
>           Inner src = 0:0:0:0:0:0:0:0 (unspecified address)
>           Inner dst = Home Agent's global address
>
>
>     6. Home Agent returns a Router Advertisement, covered by AH. An SA
>        has to be set up between MN's CoA and the HA. How this is done
>        is out of scope, but MN and HA have some shared secret
> or can be
>        verified by some agent.
>
>        The Router Advertisement is returned by tunneling, as follows:
>
>           Outer src = HA's global address
>           Outer dst = care-of address
>           Outer src = HA's home subnet link-local address
>           Inner dst = all-nodes multicast address
>
>
>     7. Mobile node parses Router Advertisement and configures all
>        prefixes and addresses according to the method stated
> there.  If
>        the the M or O flags are set in the router
> advertisement, follow
>        the stateful (DHCPv6) configuration procedures.
>
>     8. Send binding update option(s) to establish bindings for the new
>        home addresses.
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 10 20:31:17 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12760
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Nov 2000 20:31:16 -0500 (EST)
Received: from standards (47.234.32.16:4392) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB3F0B@standards.nortelnetworks.com>; Fri, 10 Nov 2000 20:12:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 97583 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 20:12:58
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:46651) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB3F09@standards.nortelnetworks.com>; Fri, 10 Nov 2000
          20:12:56 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id MAA12567 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sat, 11 Nov 2000 12:25:57
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA24105 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sat, 11 Nov 2000 12:28:42
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBDPRXR>; Sat, 11 Nov 2000 12:28:56 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613DDA@eaubrnt018.epa.ericsson.se>
Date:         Sat, 11 Nov 2000 12:28:55 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] Binding Cache entries per IPv6 address at Corresp
              ondent Node
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> >         => Yes I agree, draft-ietf-mobileip-hmipv6-  is a good
> >         example for the case Mattias mentions where the MN registers
> >         different COA's with different CNs
>
> So the mobile node can register a single "primary" HA -> CoA mapping with
> its home agent, but then after that it can give different correspondents
> different mappings?
>
        => Yep. I see your concern but nothing in the specs stops
        that and I think that's a strength. A feature ;)


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Nov 12 12:10:43 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29048
	for <mobileip-archive@LISTS.IETF.ORG>; Sun, 12 Nov 2000 12:10:43 -0500 (EST)
Received: from standards (47.234.32.16:3423) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB42AD@standards.nortelnetworks.com>; 12 Nov 2000 11:51:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 98748 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 12 Nov 2000 11:51:50
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB42AB@standards.nortelnetworks.com>; 12 Nov 2000 11:51:50 -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA00094;
          Sun, 12 Nov 2000 09:08:16 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eACH8EE11793; Sun, 12 Nov 2000 09:08:14
          -0800
X-Virus-Scanned:  Sun, 12 Nov 2000 09:08:14 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from Icharliep-1.iprg.nokia.com (205.226.22.18,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpd68kS8B; Sun, 12 Nov 2000
          09:08:09 PST
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <00a601c0445d$d6c11800$c72ebca8@ce.cnu.ac.kr>
            <3A010205.D5D2D68D@iprg.nokia.com>
            <004001c04496$de125360$c72ebca8@ce.cnu.ac.kr>
            <3A01D2B3.AD5C6E71@iprg.nokia.com>
            <01ae01c04548$7f6bb1a0$c72ebca8@ce.cnu.ac.kr>
            <3A02EB55.3C7205C5@iprg.nokia.com>
            <005101c0464f$752b3320$c72ebca8@ce.cnu.ac.kr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Charlie Perkins <charliep@IPRG.NOKIA.COM>
Message-ID:  <3A0ECE0E.8E670293@iprg.nokia.com>
Date:         Sun, 12 Nov 2000 09:06:22 -0800
Reply-To: Charlie Perkins <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Charlie Perkins <charliep@IPRG.nokia.com>
Organization: Nokia
Subject:      Re: [MOBILE-IP] Question about "Route Optimization in Mobile IP"
X-To:         "Park, Hyun Seo" <hspark@ce.cnu.ac.kr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Park,

The Binding Warning has had a long history.  The currentformulation
uses the design assumption that it's faster to ask the home agent to
send the information, than to ask the correspondent node to ask the
home agent to send it.  The original formulation had the information
going to the correspondent node.  In the situation where the home
agent is not known, then we could send the Binding Warning to the
mobile node, or to the correspondent node.

>
> > > [Park] Then, when CN receives "Binding Warning", what can CN do ?
> > >     In present Route Optimization draft, when a Node, that is, HA receives
> > >     "Binding Warning", it sends "Binding Update" to the target node in
> > >     "Binding Warning" message ... Please explain to me in detail ...
> >
> > The Correspondent Node should delete its binding for the mobile
> > node.  Then packets will go to the home network.  Then the home
> > agent will send a Binding Update, or else the mobile node will.
>
> Do you mean another use of "Binding Warning" ?
> When a HA receives "Binding Warning",
>     it should send "Binding Update" to the target node in "Binding Warning" ...
> When a CN receives "Binding Warning",
>     it should delete "Binding Cache" ...
> I think it is a little unreasonable ....
> How about my approach that is, "Binding Cache" for "Deregistered MN" ?
> I think it is more logical ...

I think it is also logical for the Binding Warning to be used for the
purpose of warning nodes about stale binding cache entries.
This could be done by specifying that the correspondent node look
for itself in the list of target addresses, or that it implicitly assumes
that it is present in the list if the list is null.

> > >> Besides, the Previous Foreign Agent Notification (PFAN) is supposed
> > >> to supply a binding with a nonzero lifetime to the previous foreign
> > >> agent.  If the home agent is the agent that issues the PFAN message,
> > >> then it should still not have a nonzero lifetime.
> > >
> > > [Park] In My Opinion, I do not think PFAN can not be used with nonzero
> > >     lifetime ....  HA can send "Binding Update" with a zero lifetime ...
> > >     Similarly, when HA receives PFAN with zero lifetime,
> > >     it can send "Binding Update" with a zero lifetime to Old FA ...
> >
> > O.K. with me.  Why would the home agent get a PFAN with zero lifetime?
>
> For "Smooth Handoff" ...
> When MN returns Home Network from Foreign Network,
>     it can send "Registration Request" (Deregistration) with attached PFAN Ext. with zero lifetime

Why wouldn't the PFAN have nonzero lifetime?  If the lifetime were nonzero,
then that would say how long the previous foreign agent should perform packet
forwarding services.

> > > [Park] What is "timing dependency with static timing parameters" ?
> > >     Perhaps I am missing something .. Please let me know ...
> > >     Thanks a lot, Charlie ...
> >
> > I was trying to imagine how a mobile agent would know when to delete
> > its entry for this:
>
> I think There is no serious problem even if a mobile agent does not delete "Binding Cache"
> for "Deregistered MN" ...
> If "Deregistered MN" moves another Foreign Network again,
>     that mobile agent can get "Binding Update" from HA after one or some packets ...
> Then that mobile agent can update its "Binding Cache" ...
> An alternative is a use of "Default Lifetime" for "Deregistered MN" ...

That is a static timing parameter.  And, nowhere else is there any mention
about keeping bindings around after they have been invalidated/deregistered.
So that also counts as a new feature, thus not a minimal solution to the
problem you raised.  However, if consensus emerges that this is a better
solution, I'll be happy to go along.

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 13 03:09:20 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20896
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Nov 2000 03:09:20 -0500 (EST)
Received: from standards (47.234.32.16:4051) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB44B4@standards.nortelnetworks.com>; Mon, 13 Nov 2000 2:50:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 99427 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 02:50:49
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB44B2@standards.nortelnetworks.com>; Mon, 13 Nov 2000 2:50:46
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAD879b30234; Mon, 13 Nov 2000 09:07:09 +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 JAA14497; Mon, 13 Nov 2000 09:07:08 +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.9.3/8.9.3) with
          ESMTP id JAA72246; Mon, 13 Nov 2000 09:09:05 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011130809.JAA72246@givry.rennes.enst-bretagne.fr>
Date:         Mon, 13 Nov 2000 09:09:05 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] Appendix
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Thu, 09 Nov 2000 13:37:46 PST. 
              <3A0B192A.472756C1@iprg.nokia.com>

 In your previous mail you wrote:

       6. Home Agent returns a Router Advertisement, covered by AH. An SA
          has to be set up between MN's CoA and the HA. How this is done
          is out of scope, but MN and HA have some shared secret or can be
          verified by some agent.

=> this is out of scope but this is not easy... If you'd like to have
interoperability then you have to give more details about the AH
(is it an transport mode AH protecting the whole Router Advertisement
but not the encapsulation, ie. something produced by a "home link
security" as proposed by McDonald at a past IETF meeting?)

Thanks

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 13 08:43:42 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08096
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Nov 2000 08:43:41 -0500 (EST)
Received: from standards (47.234.32.16:2296) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4624@standards.nortelnetworks.com>; Mon, 13 Nov 2000 8:25:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 99917 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 08:25:00
          -0500
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB4622@standards.nortelnetworks.com>; Mon, 13 Nov 2000
          8:24:59 -0500
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP
          id eADDfQt21107; Mon, 13 Nov 2000 14:41:26 +0100 (MET)
Received: from era.ericsson.se by era-t.ericsson.se
          (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id OAA01796; Mon, 13 Nov 2000 14:41:26
          +0100
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
References: <C99A689B0CB9D111AF3F0000F8062CCD08FB83C6@zkoexc2.zko.dec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Mattias Pettersson <mattias.pettersson@ERA.ERICSSON.SE>
Message-ID:  <3A0FEF7C.B139319D@era.ericsson.se>
Date:         Mon, 13 Nov 2000 14:41:16 +0100
Reply-To: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Radio Systems AB
Subject:      Re: [MOBILE-IP] Appendix
X-To:         "Powell, Ken" <Ken.Powell@compaq.com>
X-cc:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi all,

Again Ken, thanks for doing this study.

"Powell, Ken" wrote:
>
> Charlie,
>
> I must have miscommunicated something here. The
> text you proposed for appendix A has elements of
> two conflicting approaches to solve the problem
> of needing a global home address to generate a
> global home address:
>
>   A) The initial text for generating a temporary home
>      address is only needed if we use the current
>      technique of exchanging the router solicits
>      and router advertisements.
>
>   B) Steps 5 and 6 show how to send router solicitations
>      and router advertisements using tunnels in a way
>      that does not need the initial home address.
>
> If we do B, we don't need to do A.
>
> I have some big problems with B still. It was just
> a quick proposal to give a vague idea how we could
> meet Mattias's objectives. It does this by redefining
> how router solicitations and router advertisements
> are tunneled. This seriously impacts many sections
> throughout the spec and needs to be fully defined
> if we are going to use it.
>
> Last night, I decided to run through the exercise of
> finding the spec changes to support option B. I had a
> gut feeling it was going to be difficult, and it
> was. I'm including what I have so far with comments
> sliced in showing the outstanding issues and giving
> possible approaches to further changes. This is not
> complete.
>
> I think we should drop tunneling (option B) and return
> to the original proposal for appendix A. I went back
> to see how we stand with Mattias's key objectives by
> doing this.
>
> >> I would like the option to let the MN configure it's
> >> home address as if it was at home, even if it is not
> >> at home.
>
> In approach A, the initial steps that generate a
> temporary home address during the bootstrap phase
> is the only part that is different. It does revert
> to the same methods and results as if the mobile
> node were physically at home once we get over the
> bootstrap phase. The initial temporary address gets
> deleted through the time-out mechanism if it does
> not get updated through stateless address
> autoconfiguration or DHCPv6.
>
> >> What I want is to open up the possibility for the MN
> >> to go through step 2-5 without neither having a home
> >> address nor having been at home before.
>
> The mobile node does not have to be preconfigured with
> any global address. It just needs a globally unique
> interface id.
>
> >> Summary: we don't need a parallel address configuration
> >> method for mobile nodes. A mobile node will be configured
> >> exactly as if it was at home.
>
> This is the piece we can't satisfy with option A, but can
> with option B. Option A requires the additional address
> configuration method to bootstrap communications.
>
> Here are the detailed changes I came up with so far to
> support option B. Side comments are bounded with "<>".
> Are these changes really worth pursuing? Its going to
> take much more effort to scrub it properly.
>
> If we are going to adopt option B, we should do it now
> because it is not backward compatible.
>
> On page 70, replace the tunneling technique with:
> =================================================
>
>    In tunneling each such Router Advertisement to the mobile node, the
>    home agent MUST construct the packet using IPv6 encapsulation [4] as
>    follows:
>
>     -  The tunnel entry point is the home agent's IP address to
>        which the mobile node addressed its current home
>        registration. If the router advertisement is being sent
>        in response to a router solicitation from a node with no
>        current home registration, the tunnel entry point is set
>        to the exit point of the tunnel thru which the original
>        router solicitation was received.
>
>     -  The tunnel exit point is the primary care-of address. If the
>        router advertisement is being sent in response to a router
>        solicitation from a node with no current home registration,
>        the tunnel exit point is set to the entry point of the tunnel
>        thru which the original router solicitation was received.
>
>        < I think its possible to do this, but I suspect it will
>          require serious changes to existing stacks to carry the
>          tunnel source and destination address up and down the
>          stack with decapsulated packets. A possible way to avoid
>          tunnel implementation issues is to support bindings
>          on the home agent for the mobile node's link local
>          address. Once done, the kernel could use much the
>          same mechanisms to route RA/RS with link local addresses
>          as it would use for routing the mobile node's global
>          home addresses. This of course would require another
>          whole series of changes to the spec. >

This idea of registering the link-local address is very interesting. The
Mobile Node could carry out everything from RS/RA to DAD and DHCPv6
itself, without proxy functions in the HA. But somehow the idea in the
I-D is to not allow mobility for link-local addresses.

There are both pros and cons of forwarding link-local packets to the MN.
The MN gets more aware of what's happening on the home link, but at the
same time a lot of unecessary traffic is tunneled to the MN.

>
>     -  The Source Address of the inner IPv6 header is set to the
>        home agents link-local IP address on the home network.
>
>     -  The Destination Address of the inner IPv6 header is set to
>        the mobile node's home subnet link-local address.
>
>        < I first intended to use the all-nodes multicast address,
>          but didn't know if IPsec works well with multicast
>          addresses. >
>
>     -  The inner IPv6 header must be protected by IPsec [13, 11, 12]
>        to guard against malicious Router Advertisements.  The IPsec
>        protection MUST provide sender authentication, data integrity
>        protection, and replay protection, covering the Router
>        Advertisement.
>
>        < I initially considered putting this in the tunnel header,
>          but most tunneled packets from the home agent to the mobile
>          node don't require IPsec, so this would probably require
>          special logic in the tunnel code to handle. I expect
>          applying IPsec to the inner header would be easier and
>          will still achieve the intended security. >
>
>     -  The packet MUST include a Binding Request destination option
>        after the IPsec Authorization or Encapsulation header.
>
>        < Putting the Binding Request here allows the mobile node
>          to strip off the outer IPv6 headers the same as it would
>          do for any other tunneled message. >

I believe the HA should only include the BR when the RA is transmitted
on HA initiative. If the RA is being sent in response to a RS from the
MN, then the BR should be omitted.

This wouldn't be an implementation issue, would it?

>
>     -  The Binding Request destination option MUST include a Unique
>        Identifier Sub-Option (Section 5.5), with the unique identifier
>        in the sub-option data set to a value different than that in
>        any other Binding Request sent recently by this node.  The word
>        "recently" here means within the maximum likely lifetime of a
>        packet, including transit time from source to destination and
>        time spent awaiting reassembly with other fragments of the same
>        packet, if fragmented.  However, it is not required that a source
>        node know the maximum packet lifetime.  Rather, it is assumed
>        that the requirement can be met by maintaining a simple 16-bit
>        "wrap-around" counter to generate unique identifiers for Binding
>        Requests that contain a Unique Identifier Sub-Option, incremented
>        each time a Binding Request containing a Unique Identifier
>        Sub-Option is sent.
>
>        < Its going to be difficult to track the status of this
>          binding request when the mobile node has no home address
>          and has not yet created a binding. Once again, creating a
>          binding for the mobile node's link-local address would help. >

So, if we skip BR in this case, we don't have this matching problem.

On the other hand, I kind of like the idea of first registering the
link-local address, carry out the RS/RA, and then configure the home
addresses and send a BU for them. Link-local address registration could
be left to expire, after that.

>
> On page 92, replace the rules for validating
> received router advertisements on the mobile node:
> ==================================================
>
>    When a mobile node receives a tunneled Router Advertisement, it MUST
>    validate it according to the following tests:
>
>     -  The Router Advertisement was received over a tunnel whose
>        entry point was the same as the home agent address to which the
>        mobile node last sent an accepted "home registration" Binding
>        Update to register its primary care-of address. If no home
>        registration exists yet, the tunnel entry point must be the
>        same as the exist point of a tunnel through which a
>        Router Solicitation was recently transmitted.
>
>     -  The inner IPv6 packet MUST be protected by IPsec [13, 11, 12]
>        to guard against malicious Router Advertisements.  The IPsec
>        protection MUST provide sender authentication, data integrity
>        protection, and replay protection, covering the Router
>        Advertisement.
>
>     -  The inner packet contains a Binding Request destination option.
>
>     -  The Binding Request option contains a Unique Identifier
>        Sub-Option.
>
> Modify my previous proposal for sending Router
> Solicits from the mobile node to the home agent:
> ================================================
>
> The mobile node must construct and tunnel such a Router Solicitation
> packet using IPv6 encapsulation [4] as follows:
>
>  -  The tunnel entry point is the mobile node's primary care-of
>     address.
>
>  -  The tunnel destination is the home agent's global IP address.
>
>  -  The Source Address of the inner IPv6 header is set to the
>     unspecified IP address (0::0).
>
>  -  The Destination Address of the inner IPv6 header is set to
>     the all routers multicast address.
>
>  -  The tunnel header MUST be protected by IPsec [13, 11, 12] to guard
>     against malicious Router Solicitations.  The IPsec protection
>     MUST provide sender authentication, data integrity protection,
>     and replay protection, covering the Router Solicitation.
>
>     < I think we should keep this requirement if responding to
>       unauthorized probes for address information could be a bad
>       thing at some sites. >

Ok. Since the RA in return anyway requires this SA, it doesn't matter if
we create it at this stage.

>
>     < If we decide link-layer address bindings are a good thing,
>       we could send a binding update in the inner IP packet
>       for the link-layer address, and specify an Alternate Care-Of
>       suboption containing the mobile node's primary care-of
>       address. >

Yeah!

>
>  - The Router Solicitation's source link-layer address
>    option MUST be omitted.
>
>     < We may wish to change this given home subnet link layer
>       address in the inner IP header and a possibility of a
>       binding for the link layer address. >
>
> Modify my previous proposal for how the Home Agent
> receives Router Solicitations from Mobile Nodes
> =================================================
>
> The Router Solicitation may include a Binding Update
> destination option. The processing requirements described
> here for the Router Solicitation assume the Binding Update
> destination option was processed first. The home agent MAY
> return a single packet containing both the resulting Binding
> Acknowledgment destination option and a Router Advertisement.
>
>  < Remove paragraph on how to handle binding
>    updates included with the router solicitation
>    unless we implement bindings for a link-layer
>    addresses >
>
> When a home agent receives a tunneled Router Solicitation from
> a mobile node on a remote network, it MUST validate it according
> to the following tests:
>
>  - The inner packet is protected by IPsec [13, 11, 12] to guard
>    against unauthorized probes for home subnet information.  The
>    IPsec protection provides sender authentication, data integrity
>    protection, and replay protection, covering the Router
>    Solicitation.
>
>     < All the other tests are unnecessary with tunnels
>       unless we implement bindings for link-local
>       addresses. >
>
> > -----Original Message-----
> > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> > Sent: Thursday, November 09, 2000 4:38 PM
> > To: Mattias Pettersson; Powell, Ken
> > Cc: Mobile IP Mailing List
> > Subject: Appendix
> >
> >
> >
> > Hello folks,
> >
> > Here is a stab at an appendix.  It needs proofreading, but
> > I have to go for now and I thought it would be better to
> > send something defective for now and touch it up more later.
> >
> > My opinion is that a Binding Update is needed, and if it takes
> > another few hundred milliseconds, that's O.K.  So, I retained
> > that step for the part after the Router Advertisement was
> > received by the mobile node.  However, this is of course up
> > for discussion.
> >
> > I reckon the hard part will be to manage the identification
> > for the mobile node.  As Hesham mentions, NAI could be used
> > for this.  However, I am sure that everyone agrees that right
> > now is not the time for trying to complete that discussion.
> >
> > Regards,
> > Charlie P.
> >
> > =====================================================================
> >
> >
> > A. Remote Home Address Configuration
> >
> >    The method for initializing a mobile node's home addresses on
> >    power-up or after an extended period of being disconnected from
> >    the network is beyond the scope of this specification.  Whatever
> >    procedure is used should result in the mobile node having the same
> >    stateless or stateful (e.g., DHCPv6) home address autoconfiguration
> >    information it would have if it were attached to the home network.
> >    Due to the possibility that the home network could be renumbered
> >    while the mobile node is disconnected, a robust mobile
> > node would not
> >    rely solely on storing these addresses locally.
> >
> >    A mobile node MAY generate a temporary home address using the
> >    following information:
> >
> >     -  the subnet prefix from the home network's mobile agent anycast
> >        address, and
> >
> >     -  the globally unique interface identifier that would have been
> >        used to generate the link local address if the mobile node were
> >        attached directly to the home network.
> >
> >    Such a temporary address could be used to establish a binding with
> >    a home agent in the absence of any other known home addresses.  It
> >    could be created with short valid lifetime and a preferred lifetime
> >    of zero to ensure a quick transition to other addresses generated
> >    when stateless or stateful (DHCPv6) address autoconfiguration runs.
> >
> >    Such a mobile node could initialize by using the following
> > procedure:
> >
> >     1. Query DNS for the home network's mobile agent anycast address.
> >
> >     2. Generate a care-of address using stateless or stateful
> >        autoconfiguration.
> >
> >     3. Send a Home Agent Address Discovery Request message to the home
> >        network.
> >
> >     4. Receive Home Agent Address Discovery Reply message.
> >
> >     5. MN picks one Home Agent and tunnels an Router
> > Solicitation to it.
> >
> >           Outer src = care-of address
> >           Outer dst = Home Agent's global address
> >           Inner src = 0:0:0:0:0:0:0:0 (unspecified address)
> >           Inner dst = Home Agent's global address
> >
> >
> >     6. Home Agent returns a Router Advertisement, covered by AH. An SA
> >        has to be set up between MN's CoA and the HA. How this is done
> >        is out of scope, but MN and HA have some shared secret
> > or can be
> >        verified by some agent.
> >
> >        The Router Advertisement is returned by tunneling, as follows:
> >
> >           Outer src = HA's global address
> >           Outer dst = care-of address
> >           Outer src = HA's home subnet link-local address
> >           Inner dst = all-nodes multicast address
> >
> >
> >     7. Mobile node parses Router Advertisement and configures all
> >        prefixes and addresses according to the method stated
> > there.  If
> >        the the M or O flags are set in the router
> > advertisement, follow
> >        the stateful (DHCPv6) configuration procedures.
> >
> >     8. Send binding update option(s) to establish bindings for the new
> >        home addresses.
> >


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 13 10:10:24 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16698
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Nov 2000 10:10:23 -0500 (EST)
Received: from standards (47.234.32.16:2141) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4692@standards.nortelnetworks.com>; Mon, 13 Nov 2000 9:51:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 100066 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 09:51:58
          -0500
Received: from zmamail04.zma.compaq.com (mailout.zma.compaq.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB4690@standards.nortelnetworks.com>; Mon, 13 Nov 2000
          9:51:58 -0500
Received: by zmamail04.zma.compaq.com (Postfix,
          from userid 12345) id 915892EE; Mon, 13 Nov 2000 10:08:25 -0500 (EST)
Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net
          [16.103.129.42]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id
          8A7063F1; Mon, 13 Nov 2000 10:08:25 -0500 (EST)
Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service
          (5.5.2652.78) id <W5QBJ5C5>; Mon, 13 Nov 2000 10:08:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain
Approved-By:  "Powell, Ken" <Ken.Powell@COMPAQ.COM>
Message-ID:  <C99A689B0CB9D111AF3F0000F8062CCD08FB83C8@zkoexc2.zko.dec.com>
Date:         Mon, 13 Nov 2000 10:08:22 -0500
Reply-To: "Powell, Ken" <Ken.Powell@compaq.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Powell, Ken" <Ken.Powell@compaq.com>
Subject:      Re: [MOBILE-IP] Binding Cache entries per IPv6 address at Corresp
              ondent Node
X-To:         Mattias Pettersson <mattias.pettersson@era.ericsson.se>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Mattias,

> One BU is, according to the draft, enough to register all
> home addresses formed by prefixes on the home link, plus
> site- and link-local. However, I feel there is a slight
> gap in the protocol on what home addresses that's actually
> been registered. Is it pointed out somewhere else in the
> spec where the HA explicitly tells the MN about the addresses
> registered, so that the MN can prepare to receive packets to these
> addresses?

I don't remember anything in the spec to do this.

> Or, as I guess is assumed, the HA should already have
> informed the MN in an RA about what prefixes are valid.

I think this is how it works.


Ken


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 13 13:36:30 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29842
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Nov 2000 13:36:29 -0500 (EST)
Received: from standards (47.234.32.16:1946) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB47A3@standards.nortelnetworks.com>; Mon, 13 Nov 2000 13:17:53 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 100424 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 13:17:52
          -0500
Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB47A1@standards.nortelnetworks.com>; Mon, 13 Nov 2000 13:17:52
          -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id NAA29105; Mon, 13 Nov 2000 13:34:17
          -0500 (EST)
Approved-By:  scoya@CNRI.RESTON.VA.US
Message-ID:  <200011131834.NAA29105@ietf.org>
Date:         Mon, 13 Nov 2000 13:34:17 -0500
Reply-To: The IESG <iesg-secretary@ietf.org>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> CC field duplicated. Last occurrence was
              retained.
Comments:     RFC822 error: <W> CC field duplicated. Last occurrence was
              retained.
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: The IESG <iesg-secretary@ietf.org>
Subject:      [MOBILE-IP] Protocol Action: Mobile IP
              Vendor/Organization-Specific
              Extensions to Proposed Standard
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

The IESG has approved the Internet-Draft 'Mobile IP
Vendor/Organization-Specific Extensions'
<draft-ietf-mobileip-vendor-ext-11.txt> as a Proposed Standard.  This
document is the product of the IP Routing for Wireless/Mobile Hosts
Working Group.  The IESG contact persons are David Oran and Rob
Coltun.


Technical Summary

The vendor/organization specific extension I-D specifies two new
extensions to the Mobile IP protocol (RFC2002). The current specification
of Mobile IP [1] does not allow for organizations and vendors
to include organization/vendor-specific information in the Mobile IP
messages. The two new extensions proposed in the I-D (Critical and
Non-Critical Vendor Specific Extensions) add this capability to Mobile
IP.

Vendors who are implementing Mobile IP in their products require the
capability of sending vendor specific information in Mobile IP
messages. These extensions are a way of enabling them to do so.


Working Group Summary

No significant or for that matter any dissent was expressed by the WG
about this I-D. Most vendors who are implementing or have
implementations welcome this capability to Mobile IP. Also the TR45.6
body in the TIA expressed support for this I-D.

Protocol Quality

The proposal in this I-D is the addition of two new extensions to
Mobile IP and not really a protocol by itself.
There are currently no known implementations of these extensions. The
extensions are intended to be specifically used by vendors for their
own needs and hence there is no question about interoperability
between implementations.

This specification was reviewed for the IESG by Dave Oran


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 13 16:39:25 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02566
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Nov 2000 16:39:24 -0500 (EST)
Received: from standards (47.234.32.16:1476) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB489F@standards.nortelnetworks.com>; Mon, 13 Nov 2000 16:20:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 100773 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 16:20:49
          -0500
Received: from zmamail04.zma.compaq.com (mailout.zma.compaq.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB489D@standards.nortelnetworks.com>; Mon, 13 Nov 2000
          16:20:48 -0500
Received: by zmamail04.zma.compaq.com (Postfix,
          from userid 12345) id E70EC237; Mon, 13 Nov 2000 16:37:18 -0500 (EST)
Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net
          [16.103.129.42]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id
          DAA681D2; Mon, 13 Nov 2000 16:37:18 -0500 (EST)
Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service
          (5.5.2652.78) id <W5QBK9AX>; Mon, 13 Nov 2000 16:37:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain
Approved-By:  "Powell, Ken" <Ken.Powell@COMPAQ.COM>
Message-ID:  <C99A689B0CB9D111AF3F0000F8062CCD08FB83CA@zkoexc2.zko.dec.com>
Date:         Mon, 13 Nov 2000 16:37:15 -0500
Reply-To: "Powell, Ken" <Ken.Powell@compaq.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Powell, Ken" <Ken.Powell@compaq.com>
Subject:      Re: [MOBILE-IP] Appendix
X-To:         Mattias Pettersson <mattias.pettersson@era.ericsson.se>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Can we back up a bit? We are headed down a long
process to redefine how router advertisements
and solicitations are sent, adding binding support
for link-local addresses, and probably rethinking
the IPsec details for this exchange. This isn't a
trivial effort. It will take time and require
careful review. Do we really want to proceed
with this? If so, could we get an updated snapshot
of the spec before we proceed too far? I'm in the
mode of defining changes to changes now.

Thoughts?

> -----Original Message-----
> From: Mattias Pettersson [mailto:mattias.pettersson@era.ericsson.se]
> Sent: Monday, November 13, 2000 8:41 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] Appendix
>
>
> Hi all,
>
> Again Ken, thanks for doing this study.
>
> "Powell, Ken" wrote:
> >
> > Charlie,
> >
> > I must have miscommunicated something here. The
> > text you proposed for appendix A has elements of
> > two conflicting approaches to solve the problem
> > of needing a global home address to generate a
> > global home address:
> >
> >   A) The initial text for generating a temporary home
> >      address is only needed if we use the current
> >      technique of exchanging the router solicits
> >      and router advertisements.
> >
> >   B) Steps 5 and 6 show how to send router solicitations
> >      and router advertisements using tunnels in a way
> >      that does not need the initial home address.
> >
> > If we do B, we don't need to do A.
> >
> > I have some big problems with B still. It was just
> > a quick proposal to give a vague idea how we could
> > meet Mattias's objectives. It does this by redefining
> > how router solicitations and router advertisements
> > are tunneled. This seriously impacts many sections
> > throughout the spec and needs to be fully defined
> > if we are going to use it.
> >
> > Last night, I decided to run through the exercise of
> > finding the spec changes to support option B. I had a
> > gut feeling it was going to be difficult, and it
> > was. I'm including what I have so far with comments
> > sliced in showing the outstanding issues and giving
> > possible approaches to further changes. This is not
> > complete.
> >
> > I think we should drop tunneling (option B) and return
> > to the original proposal for appendix A. I went back
> > to see how we stand with Mattias's key objectives by
> > doing this.
> >
> > >> I would like the option to let the MN configure it's
> > >> home address as if it was at home, even if it is not
> > >> at home.
> >
> > In approach A, the initial steps that generate a
> > temporary home address during the bootstrap phase
> > is the only part that is different. It does revert
> > to the same methods and results as if the mobile
> > node were physically at home once we get over the
> > bootstrap phase. The initial temporary address gets
> > deleted through the time-out mechanism if it does
> > not get updated through stateless address
> > autoconfiguration or DHCPv6.
> >
> > >> What I want is to open up the possibility for the MN
> > >> to go through step 2-5 without neither having a home
> > >> address nor having been at home before.
> >
> > The mobile node does not have to be preconfigured with
> > any global address. It just needs a globally unique
> > interface id.
> >
> > >> Summary: we don't need a parallel address configuration
> > >> method for mobile nodes. A mobile node will be configured
> > >> exactly as if it was at home.
> >
> > This is the piece we can't satisfy with option A, but can
> > with option B. Option A requires the additional address
> > configuration method to bootstrap communications.
> >
> > Here are the detailed changes I came up with so far to
> > support option B. Side comments are bounded with "<>".
> > Are these changes really worth pursuing? Its going to
> > take much more effort to scrub it properly.
> >
> > If we are going to adopt option B, we should do it now
> > because it is not backward compatible.
> >
> > On page 70, replace the tunneling technique with:
> > =================================================
> >
> >    In tunneling each such Router Advertisement to the
> mobile node, the
> >    home agent MUST construct the packet using IPv6
> encapsulation [4] as
> >    follows:
> >
> >     -  The tunnel entry point is the home agent's IP address to
> >        which the mobile node addressed its current home
> >        registration. If the router advertisement is being sent
> >        in response to a router solicitation from a node with no
> >        current home registration, the tunnel entry point is set
> >        to the exit point of the tunnel thru which the original
> >        router solicitation was received.
> >
> >     -  The tunnel exit point is the primary care-of address. If the
> >        router advertisement is being sent in response to a router
> >        solicitation from a node with no current home registration,
> >        the tunnel exit point is set to the entry point of the tunnel
> >        thru which the original router solicitation was received.
> >
> >        < I think its possible to do this, but I suspect it will
> >          require serious changes to existing stacks to carry the
> >          tunnel source and destination address up and down the
> >          stack with decapsulated packets. A possible way to avoid
> >          tunnel implementation issues is to support bindings
> >          on the home agent for the mobile node's link local
> >          address. Once done, the kernel could use much the
> >          same mechanisms to route RA/RS with link local addresses
> >          as it would use for routing the mobile node's global
> >          home addresses. This of course would require another
> >          whole series of changes to the spec. >
>
> This idea of registering the link-local address is very
> interesting. The
> Mobile Node could carry out everything from RS/RA to DAD and DHCPv6
> itself, without proxy functions in the HA. But somehow the idea in the
> I-D is to not allow mobility for link-local addresses.
>
> There are both pros and cons of forwarding link-local packets
> to the MN.
> The MN gets more aware of what's happening on the home link,
> but at the
> same time a lot of unecessary traffic is tunneled to the MN.

I would recommend against forwarding any link-local traffic
between the home network and the mobile node. The overhead
traffic of a lower cost home network could become a major
problem on wireless links. I had intended to keep the proxy
functions in the home agent and use link-local bindings to
support traffic between the mobile node and the home agent
only.

>
> >
> >     -  The Source Address of the inner IPv6 header is set to the
> >        home agents link-local IP address on the home network.
> >
> >     -  The Destination Address of the inner IPv6 header is set to
> >        the mobile node's home subnet link-local address.
> >
> >        < I first intended to use the all-nodes multicast address,
> >          but didn't know if IPsec works well with multicast
> >          addresses. >
> >
> >     -  The inner IPv6 header must be protected by IPsec [13, 11, 12]
> >        to guard against malicious Router Advertisements.  The IPsec
> >        protection MUST provide sender authentication, data integrity
> >        protection, and replay protection, covering the Router
> >        Advertisement.
> >
> >        < I initially considered putting this in the tunnel header,
> >          but most tunneled packets from the home agent to the mobile
> >          node don't require IPsec, so this would probably require
> >          special logic in the tunnel code to handle. I expect
> >          applying IPsec to the inner header would be easier and
> >          will still achieve the intended security. >
> >
> >     -  The packet MUST include a Binding Request destination option
> >        after the IPsec Authorization or Encapsulation header.
> >
> >        < Putting the Binding Request here allows the mobile node
> >          to strip off the outer IPv6 headers the same as it would
> >          do for any other tunneled message. >
>
> I believe the HA should only include the BR when the RA is transmitted
> on HA initiative. If the RA is being sent in response to a RS from the
> MN, then the BR should be omitted.
>
> This wouldn't be an implementation issue, would it?

This would add special case in the algorithm to send router
advertisements that I don't think is needed.

>
> >
> >     -  The Binding Request destination option MUST include a Unique
> >        Identifier Sub-Option (Section 5.5), with the unique
> identifier
> >        in the sub-option data set to a value different than that in
> >        any other Binding Request sent recently by this
> node.  The word
> >        "recently" here means within the maximum likely lifetime of a
> >        packet, including transit time from source to destination and
> >        time spent awaiting reassembly with other fragments
> of the same
> >        packet, if fragmented.  However, it is not required
> that a source
> >        node know the maximum packet lifetime.  Rather, it is assumed
> >        that the requirement can be met by maintaining a
> simple 16-bit
> >        "wrap-around" counter to generate unique identifiers
> for Binding
> >        Requests that contain a Unique Identifier
> Sub-Option, incremented
> >        each time a Binding Request containing a Unique Identifier
> >        Sub-Option is sent.
> >
> >        < Its going to be difficult to track the status of this
> >          binding request when the mobile node has no home address
> >          and has not yet created a binding. Once again, creating a
> >          binding for the mobile node's link-local address
> would help. >
>
> So, if we skip BR in this case, we don't have this matching problem.
>
> On the other hand, I kind of like the idea of first registering the
> link-local address, carry out the RS/RA, and then configure the home
> addresses and send a BU for them. Link-local address
> registration could
> be left to expire, after that.

Thats just what I was thinking, except that I believe
it would be better to make the link-local addresses
be permanent and always use link-locals only for RS/RA
exchange. This would allow the RS/RA addresses map
more closely to what is used on the home subnet.

>
> >
> > On page 92, replace the rules for validating
> > received router advertisements on the mobile node:
> > ==================================================
> >
> >    When a mobile node receives a tunneled Router
> Advertisement, it MUST
> >    validate it according to the following tests:
> >
> >     -  The Router Advertisement was received over a tunnel whose
> >        entry point was the same as the home agent address
> to which the
> >        mobile node last sent an accepted "home registration" Binding
> >        Update to register its primary care-of address. If no home
> >        registration exists yet, the tunnel entry point must be the
> >        same as the exist point of a tunnel through which a
> >        Router Solicitation was recently transmitted.
> >
> >     -  The inner IPv6 packet MUST be protected by IPsec [13, 11, 12]
> >        to guard against malicious Router Advertisements.  The IPsec
> >        protection MUST provide sender authentication, data integrity
> >        protection, and replay protection, covering the Router
> >        Advertisement.
> >
> >     -  The inner packet contains a Binding Request
> destination option.
> >
> >     -  The Binding Request option contains a Unique Identifier
> >        Sub-Option.
> >
> > Modify my previous proposal for sending Router
> > Solicits from the mobile node to the home agent:
> > ================================================
> >
> > The mobile node must construct and tunnel such a Router Solicitation
> > packet using IPv6 encapsulation [4] as follows:
> >
> >  -  The tunnel entry point is the mobile node's primary care-of
> >     address.
> >
> >  -  The tunnel destination is the home agent's global IP address.
> >
> >  -  The Source Address of the inner IPv6 header is set to the
> >     unspecified IP address (0::0).
> >
> >  -  The Destination Address of the inner IPv6 header is set to
> >     the all routers multicast address.
> >
> >  -  The tunnel header MUST be protected by IPsec [13, 11,
> 12] to guard
> >     against malicious Router Solicitations.  The IPsec protection
> >     MUST provide sender authentication, data integrity protection,
> >     and replay protection, covering the Router Solicitation.
> >
> >     < I think we should keep this requirement if responding to
> >       unauthorized probes for address information could be a bad
> >       thing at some sites. >
>
> Ok. Since the RA in return anyway requires this SA, it
> doesn't matter if
> we create it at this stage.
>
> >
> >     < If we decide link-layer address bindings are a good thing,
> >       we could send a binding update in the inner IP packet
> >       for the link-layer address, and specify an Alternate Care-Of
> >       suboption containing the mobile node's primary care-of
> >       address. >
>
> Yeah!

Another catch, How does one return a binding ack for a failed link
local binding atempt?

>
> >
> >  - The Router Solicitation's source link-layer address
> >    option MUST be omitted.
> >
> >     < We may wish to change this given home subnet link layer
> >       address in the inner IP header and a possibility of a
> >       binding for the link layer address. >
> >
> > Modify my previous proposal for how the Home Agent
> > receives Router Solicitations from Mobile Nodes
> > =================================================
> >
> > The Router Solicitation may include a Binding Update
> > destination option. The processing requirements described
> > here for the Router Solicitation assume the Binding Update
> > destination option was processed first. The home agent MAY
> > return a single packet containing both the resulting Binding
> > Acknowledgment destination option and a Router Advertisement.
> >
> >  < Remove paragraph on how to handle binding
> >    updates included with the router solicitation
> >    unless we implement bindings for a link-layer
> >    addresses >
> >
> > When a home agent receives a tunneled Router Solicitation from
> > a mobile node on a remote network, it MUST validate it according
> > to the following tests:
> >
> >  - The inner packet is protected by IPsec [13, 11, 12] to guard
> >    against unauthorized probes for home subnet information.  The
> >    IPsec protection provides sender authentication, data integrity
> >    protection, and replay protection, covering the Router
> >    Solicitation.
> >
> >     < All the other tests are unnecessary with tunnels
> >       unless we implement bindings for link-local
> >       addresses. >
> >
> > > -----Original Message-----
> > > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> > > Sent: Thursday, November 09, 2000 4:38 PM
> > > To: Mattias Pettersson; Powell, Ken
> > > Cc: Mobile IP Mailing List
> > > Subject: Appendix
> > >
> > >
> > >
> > > Hello folks,
> > >
> > > Here is a stab at an appendix.  It needs proofreading, but
> > > I have to go for now and I thought it would be better to
> > > send something defective for now and touch it up more later.
> > >
> > > My opinion is that a Binding Update is needed, and if it takes
> > > another few hundred milliseconds, that's O.K.  So, I retained
> > > that step for the part after the Router Advertisement was
> > > received by the mobile node.  However, this is of course up
> > > for discussion.
> > >
> > > I reckon the hard part will be to manage the identification
> > > for the mobile node.  As Hesham mentions, NAI could be used
> > > for this.  However, I am sure that everyone agrees that right
> > > now is not the time for trying to complete that discussion.
> > >
> > > Regards,
> > > Charlie P.
> > >
> > >
> =====================================================================
> > >
> > >
> > > A. Remote Home Address Configuration
> > >
> > >    The method for initializing a mobile node's home addresses on
> > >    power-up or after an extended period of being disconnected from
> > >    the network is beyond the scope of this specification.
>  Whatever
> > >    procedure is used should result in the mobile node
> having the same
> > >    stateless or stateful (e.g., DHCPv6) home address
> autoconfiguration
> > >    information it would have if it were attached to the
> home network.
> > >    Due to the possibility that the home network could be
> renumbered
> > >    while the mobile node is disconnected, a robust mobile
> > > node would not
> > >    rely solely on storing these addresses locally.
> > >
> > >    A mobile node MAY generate a temporary home address using the
> > >    following information:
> > >
> > >     -  the subnet prefix from the home network's mobile
> agent anycast
> > >        address, and
> > >
> > >     -  the globally unique interface identifier that
> would have been
> > >        used to generate the link local address if the
> mobile node were
> > >        attached directly to the home network.
> > >
> > >    Such a temporary address could be used to establish a
> binding with
> > >    a home agent in the absence of any other known home
> addresses.  It
> > >    could be created with short valid lifetime and a
> preferred lifetime
> > >    of zero to ensure a quick transition to other
> addresses generated
> > >    when stateless or stateful (DHCPv6) address
> autoconfiguration runs.
> > >
> > >    Such a mobile node could initialize by using the following
> > > procedure:
> > >
> > >     1. Query DNS for the home network's mobile agent
> anycast address.
> > >
> > >     2. Generate a care-of address using stateless or stateful
> > >        autoconfiguration.
> > >
> > >     3. Send a Home Agent Address Discovery Request
> message to the home
> > >        network.
> > >
> > >     4. Receive Home Agent Address Discovery Reply message.
> > >
> > >     5. MN picks one Home Agent and tunnels an Router
> > > Solicitation to it.
> > >
> > >           Outer src = care-of address
> > >           Outer dst = Home Agent's global address
> > >           Inner src = 0:0:0:0:0:0:0:0 (unspecified address)
> > >           Inner dst = Home Agent's global address
> > >
> > >
> > >     6. Home Agent returns a Router Advertisement, covered
> by AH. An SA
> > >        has to be set up between MN's CoA and the HA. How
> this is done
> > >        is out of scope, but MN and HA have some shared secret
> > > or can be
> > >        verified by some agent.
> > >
> > >        The Router Advertisement is returned by tunneling,
> as follows:
> > >
> > >           Outer src = HA's global address
> > >           Outer dst = care-of address
> > >           Outer src = HA's home subnet link-local address
> > >           Inner dst = all-nodes multicast address
> > >
> > >
> > >     7. Mobile node parses Router Advertisement and configures all
> > >        prefixes and addresses according to the method stated
> > > there.  If
> > >        the the M or O flags are set in the router
> > > advertisement, follow
> > >        the stateful (DHCPv6) configuration procedures.
> > >
> > >     8. Send binding update option(s) to establish
> bindings for the new
> > >        home addresses.
> > >
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 13 16:52:43 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05754
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Nov 2000 16:52:42 -0500 (EST)
Received: from standards (47.234.32.16:1476) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB48FB@standards.nortelnetworks.com>; Mon, 13 Nov 2000 16:34:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 100894 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 16:34:16
          -0500
Received: from chntva1-smrly1.gtei.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB48F9@standards.nortelnetworks.com>; Mon, 13 Nov 2000 16:34:07
          -0500
Received: from deptvachi-cp.va.gov (deptvachi-cp.va.gov [205.183.31.120]) by
          chntva1-smrly1.gtei.net (Postfix) with SMTP id 984503B3D; Mon, 13 Nov
          2000 21:50:36 +0000 (GMT)
Received: from 152.129.1.17 by vhaishmulv (InterScan E-Mail VirusWall NT); Mon,
          13 Nov 2000 15:49:08 -0600 (Central Standard Time)
Received: by VHAISHEXCI.med.va.gov with Internet Mail Service (5.5.2650.21) id
          <WSKHDNNG>; Mon, 13 Nov 2000 15:50:12 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C04DBC.10870B50"
Approved-By:  "Kay, Rodney" <Rodney.Kay@MED.VA.GOV>
Message-ID:  <2A5485D1C9C7D311816F0000F805ADB769712A@vhapugexc1.med.va.gov>
Date:         Mon, 13 Nov 2000 15:52:49 -0600
Reply-To: "Kay, Rodney" <Rodney.Kay@med.va.gov>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Kay, Rodney" <Rodney.Kay@med.va.gov>
Subject:      Re: [MOBILE-IP] Appendix
X-To:         "Powell, Ken" <Ken.Powell@compaq.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

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

------_=_NextPart_000_01C04DBC.10870B50
Content-Type: text/plain;
        charset="iso-8859-1"

Agreed!

Rodney H. Kay
Department of Veterans Affairs
Puget Sound Health Care System
Systems Manager
Seattle, Washington  98108


-----Original Message-----
From: Powell, Ken [mailto:Ken.Powell@compaq.com]
Sent: Monday, November 13, 2000 1:37 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] Appendix


Can we back up a bit? We are headed down a long
process to redefine how router advertisements
and solicitations are sent, adding binding support
for link-local addresses, and probably rethinking
the IPsec details for this exchange. This isn't a
trivial effort. It will take time and require
careful review. Do we really want to proceed
with this? If so, could we get an updated snapshot
of the spec before we proceed too far? I'm in the
mode of defining changes to changes now.

Thoughts?

> -----Original Message-----
> From: Mattias Pettersson [mailto:mattias.pettersson@era.ericsson.se]
> Sent: Monday, November 13, 2000 8:41 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] Appendix
>
>
> Hi all,
>
> Again Ken, thanks for doing this study.
>
> "Powell, Ken" wrote:
> >
> > Charlie,
> >
> > I must have miscommunicated something here. The
> > text you proposed for appendix A has elements of
> > two conflicting approaches to solve the problem
> > of needing a global home address to generate a
> > global home address:
> >
> >   A) The initial text for generating a temporary home
> >      address is only needed if we use the current
> >      technique of exchanging the router solicits
> >      and router advertisements.
> >
> >   B) Steps 5 and 6 show how to send router solicitations
> >      and router advertisements using tunnels in a way
> >      that does not need the initial home address.
> >
> > If we do B, we don't need to do A.
> >
> > I have some big problems with B still. It was just
> > a quick proposal to give a vague idea how we could
> > meet Mattias's objectives. It does this by redefining
> > how router solicitations and router advertisements
> > are tunneled. This seriously impacts many sections
> > throughout the spec and needs to be fully defined
> > if we are going to use it.
> >
> > Last night, I decided to run through the exercise of
> > finding the spec changes to support option B. I had a
> > gut feeling it was going to be difficult, and it
> > was. I'm including what I have so far with comments
> > sliced in showing the outstanding issues and giving
> > possible approaches to further changes. This is not
> > complete.
> >
> > I think we should drop tunneling (option B) and return
> > to the original proposal for appendix A. I went back
> > to see how we stand with Mattias's key objectives by
> > doing this.
> >
> > >> I would like the option to let the MN configure it's
> > >> home address as if it was at home, even if it is not
> > >> at home.
> >
> > In approach A, the initial steps that generate a
> > temporary home address during the bootstrap phase
> > is the only part that is different. It does revert
> > to the same methods and results as if the mobile
> > node were physically at home once we get over the
> > bootstrap phase. The initial temporary address gets
> > deleted through the time-out mechanism if it does
> > not get updated through stateless address
> > autoconfiguration or DHCPv6.
> >
> > >> What I want is to open up the possibility for the MN
> > >> to go through step 2-5 without neither having a home
> > >> address nor having been at home before.
> >
> > The mobile node does not have to be preconfigured with
> > any global address. It just needs a globally unique
> > interface id.
> >
> > >> Summary: we don't need a parallel address configuration
> > >> method for mobile nodes. A mobile node will be configured
> > >> exactly as if it was at home.
> >
> > This is the piece we can't satisfy with option A, but can
> > with option B. Option A requires the additional address
> > configuration method to bootstrap communications.
> >
> > Here are the detailed changes I came up with so far to
> > support option B. Side comments are bounded with "<>".
> > Are these changes really worth pursuing? Its going to
> > take much more effort to scrub it properly.
> >
> > If we are going to adopt option B, we should do it now
> > because it is not backward compatible.
> >
> > On page 70, replace the tunneling technique with:
> > =================================================
> >
> >    In tunneling each such Router Advertisement to the
> mobile node, the
> >    home agent MUST construct the packet using IPv6
> encapsulation [4] as
> >    follows:
> >
> >     -  The tunnel entry point is the home agent's IP address to
> >        which the mobile node addressed its current home
> >        registration. If the router advertisement is being sent
> >        in response to a router solicitation from a node with no
> >        current home registration, the tunnel entry point is set
> >        to the exit point of the tunnel thru which the original
> >        router solicitation was received.
> >
> >     -  The tunnel exit point is the primary care-of address. If the
> >        router advertisement is being sent in response to a router
> >        solicitation from a node with no current home registration,
> >        the tunnel exit point is set to the entry point of the tunnel
> >        thru which the original router solicitation was received.
> >
> >        < I think its possible to do this, but I suspect it will
> >          require serious changes to existing stacks to carry the
> >          tunnel source and destination address up and down the
> >          stack with decapsulated packets. A possible way to avoid
> >          tunnel implementation issues is to support bindings
> >          on the home agent for the mobile node's link local
> >          address. Once done, the kernel could use much the
> >          same mechanisms to route RA/RS with link local addresses
> >          as it would use for routing the mobile node's global
> >          home addresses. This of course would require another
> >          whole series of changes to the spec. >
>
> This idea of registering the link-local address is very
> interesting. The
> Mobile Node could carry out everything from RS/RA to DAD and DHCPv6
> itself, without proxy functions in the HA. But somehow the idea in the
> I-D is to not allow mobility for link-local addresses.
>
> There are both pros and cons of forwarding link-local packets
> to the MN.
> The MN gets more aware of what's happening on the home link,
> but at the
> same time a lot of unecessary traffic is tunneled to the MN.

I would recommend against forwarding any link-local traffic
between the home network and the mobile node. The overhead
traffic of a lower cost home network could become a major
problem on wireless links. I had intended to keep the proxy
functions in the home agent and use link-local bindings to
support traffic between the mobile node and the home agent
only.

>
> >
> >     -  The Source Address of the inner IPv6 header is set to the
> >        home agents link-local IP address on the home network.
> >
> >     -  The Destination Address of the inner IPv6 header is set to
> >        the mobile node's home subnet link-local address.
> >
> >        < I first intended to use the all-nodes multicast address,
> >          but didn't know if IPsec works well with multicast
> >          addresses. >
> >
> >     -  The inner IPv6 header must be protected by IPsec [13, 11, 12]
> >        to guard against malicious Router Advertisements.  The IPsec
> >        protection MUST provide sender authentication, data integrity
> >        protection, and replay protection, covering the Router
> >        Advertisement.
> >
> >        < I initially considered putting this in the tunnel header,
> >          but most tunneled packets from the home agent to the mobile
> >          node don't require IPsec, so this would probably require
> >          special logic in the tunnel code to handle. I expect
> >          applying IPsec to the inner header would be easier and
> >          will still achieve the intended security. >
> >
> >     -  The packet MUST include a Binding Request destination option
> >        after the IPsec Authorization or Encapsulation header.
> >
> >        < Putting the Binding Request here allows the mobile node
> >          to strip off the outer IPv6 headers the same as it would
> >          do for any other tunneled message. >
>
> I believe the HA should only include the BR when the RA is transmitted
> on HA initiative. If the RA is being sent in response to a RS from the
> MN, then the BR should be omitted.
>
> This wouldn't be an implementation issue, would it?

This would add special case in the algorithm to send router
advertisements that I don't think is needed.

>
> >
> >     -  The Binding Request destination option MUST include a Unique
> >        Identifier Sub-Option (Section 5.5), with the unique
> identifier
> >        in the sub-option data set to a value different than that in
> >        any other Binding Request sent recently by this
> node.  The word
> >        "recently" here means within the maximum likely lifetime of a
> >        packet, including transit time from source to destination and
> >        time spent awaiting reassembly with other fragments
> of the same
> >        packet, if fragmented.  However, it is not required
> that a source
> >        node know the maximum packet lifetime.  Rather, it is assumed
> >        that the requirement can be met by maintaining a
> simple 16-bit
> >        "wrap-around" counter to generate unique identifiers
> for Binding
> >        Requests that contain a Unique Identifier
> Sub-Option, incremented
> >        each time a Binding Request containing a Unique Identifier
> >        Sub-Option is sent.
> >
> >        < Its going to be difficult to track the status of this
> >          binding request when the mobile node has no home address
> >          and has not yet created a binding. Once again, creating a
> >          binding for the mobile node's link-local address
> would help. >
>
> So, if we skip BR in this case, we don't have this matching problem.
>
> On the other hand, I kind of like the idea of first registering the
> link-local address, carry out the RS/RA, and then configure the home
> addresses and send a BU for them. Link-local address
> registration could
> be left to expire, after that.

Thats just what I was thinking, except that I believe
it would be better to make the link-local addresses
be permanent and always use link-locals only for RS/RA
exchange. This would allow the RS/RA addresses map
more closely to what is used on the home subnet.

>
> >
> > On page 92, replace the rules for validating
> > received router advertisements on the mobile node:
> > ==================================================
> >
> >    When a mobile node receives a tunneled Router
> Advertisement, it MUST
> >    validate it according to the following tests:
> >
> >     -  The Router Advertisement was received over a tunnel whose
> >        entry point was the same as the home agent address
> to which the
> >        mobile node last sent an accepted "home registration" Binding
> >        Update to register its primary care-of address. If no home
> >        registration exists yet, the tunnel entry point must be the
> >        same as the exist point of a tunnel through which a
> >        Router Solicitation was recently transmitted.
> >
> >     -  The inner IPv6 packet MUST be protected by IPsec [13, 11, 12]
> >        to guard against malicious Router Advertisements.  The IPsec
> >        protection MUST provide sender authentication, data integrity
> >        protection, and replay protection, covering the Router
> >        Advertisement.
> >
> >     -  The inner packet contains a Binding Request
> destination option.
> >
> >     -  The Binding Request option contains a Unique Identifier
> >        Sub-Option.
> >
> > Modify my previous proposal for sending Router
> > Solicits from the mobile node to the home agent:
> > ================================================
> >
> > The mobile node must construct and tunnel such a Router Solicitation
> > packet using IPv6 encapsulation [4] as follows:
> >
> >  -  The tunnel entry point is the mobile node's primary care-of
> >     address.
> >
> >  -  The tunnel destination is the home agent's global IP address.
> >
> >  -  The Source Address of the inner IPv6 header is set to the
> >     unspecified IP address (0::0).
> >
> >  -  The Destination Address of the inner IPv6 header is set to
> >     the all routers multicast address.
> >
> >  -  The tunnel header MUST be protected by IPsec [13, 11,
> 12] to guard
> >     against malicious Router Solicitations.  The IPsec protection
> >     MUST provide sender authentication, data integrity protection,
> >     and replay protection, covering the Router Solicitation.
> >
> >     < I think we should keep this requirement if responding to
> >       unauthorized probes for address information could be a bad
> >       thing at some sites. >
>
> Ok. Since the RA in return anyway requires this SA, it
> doesn't matter if
> we create it at this stage.
>
> >
> >     < If we decide link-layer address bindings are a good thing,
> >       we could send a binding update in the inner IP packet
> >       for the link-layer address, and specify an Alternate Care-Of
> >       suboption containing the mobile node's primary care-of
> >       address. >
>
> Yeah!

Another catch, How does one return a binding ack for a failed link
local binding atempt?

>
> >
> >  - The Router Solicitation's source link-layer address
> >    option MUST be omitted.
> >
> >     < We may wish to change this given home subnet link layer
> >       address in the inner IP header and a possibility of a
> >       binding for the link layer address. >
> >
> > Modify my previous proposal for how the Home Agent
> > receives Router Solicitations from Mobile Nodes
> > =================================================
> >
> > The Router Solicitation may include a Binding Update
> > destination option. The processing requirements described
> > here for the Router Solicitation assume the Binding Update
> > destination option was processed first. The home agent MAY
> > return a single packet containing both the resulting Binding
> > Acknowledgment destination option and a Router Advertisement.
> >
> >  < Remove paragraph on how to handle binding
> >    updates included with the router solicitation
> >    unless we implement bindings for a link-layer
> >    addresses >
> >
> > When a home agent receives a tunneled Router Solicitation from
> > a mobile node on a remote network, it MUST validate it according
> > to the following tests:
> >
> >  - The inner packet is protected by IPsec [13, 11, 12] to guard
> >    against unauthorized probes for home subnet information.  The
> >    IPsec protection provides sender authentication, data integrity
> >    protection, and replay protection, covering the Router
> >    Solicitation.
> >
> >     < All the other tests are unnecessary with tunnels
> >       unless we implement bindings for link-local
> >       addresses. >
> >
> > > -----Original Message-----
> > > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> > > Sent: Thursday, November 09, 2000 4:38 PM
> > > To: Mattias Pettersson; Powell, Ken
> > > Cc: Mobile IP Mailing List
> > > Subject: Appendix
> > >
> > >
> > >
> > > Hello folks,
> > >
> > > Here is a stab at an appendix.  It needs proofreading, but
> > > I have to go for now and I thought it would be better to
> > > send something defective for now and touch it up more later.
> > >
> > > My opinion is that a Binding Update is needed, and if it takes
> > > another few hundred milliseconds, that's O.K.  So, I retained
> > > that step for the part after the Router Advertisement was
> > > received by the mobile node.  However, this is of course up
> > > for discussion.
> > >
> > > I reckon the hard part will be to manage the identification
> > > for the mobile node.  As Hesham mentions, NAI could be used
> > > for this.  However, I am sure that everyone agrees that right
> > > now is not the time for trying to complete that discussion.
> > >
> > > Regards,
> > > Charlie P.
> > >
> > >
> =====================================================================
> > >
> > >
> > > A. Remote Home Address Configuration
> > >
> > >    The method for initializing a mobile node's home addresses on
> > >    power-up or after an extended period of being disconnected from
> > >    the network is beyond the scope of this specification.
>  Whatever
> > >    procedure is used should result in the mobile node
> having the same
> > >    stateless or stateful (e.g., DHCPv6) home address
> autoconfiguration
> > >    information it would have if it were attached to the
> home network.
> > >    Due to the possibility that the home network could be
> renumbered
> > >    while the mobile node is disconnected, a robust mobile
> > > node would not
> > >    rely solely on storing these addresses locally.
> > >
> > >    A mobile node MAY generate a temporary home address using the
> > >    following information:
> > >
> > >     -  the subnet prefix from the home network's mobile
> agent anycast
> > >        address, and
> > >
> > >     -  the globally unique interface identifier that
> would have been
> > >        used to generate the link local address if the
> mobile node were
> > >        attached directly to the home network.
> > >
> > >    Such a temporary address could be used to establish a
> binding with
> > >    a home agent in the absence of any other known home
> addresses.  It
> > >    could be created with short valid lifetime and a
> preferred lifetime
> > >    of zero to ensure a quick transition to other
> addresses generated
> > >    when stateless or stateful (DHCPv6) address
> autoconfiguration runs.
> > >
> > >    Such a mobile node could initialize by using the following
> > > procedure:
> > >
> > >     1. Query DNS for the home network's mobile agent
> anycast address.
> > >
> > >     2. Generate a care-of address using stateless or stateful
> > >        autoconfiguration.
> > >
> > >     3. Send a Home Agent Address Discovery Request
> message to the home
> > >        network.
> > >
> > >     4. Receive Home Agent Address Discovery Reply message.
> > >
> > >     5. MN picks one Home Agent and tunnels an Router
> > > Solicitation to it.
> > >
> > >           Outer src = care-of address
> > >           Outer dst = Home Agent's global address
> > >           Inner src = 0:0:0:0:0:0:0:0 (unspecified address)
> > >           Inner dst = Home Agent's global address
> > >
> > >
> > >     6. Home Agent returns a Router Advertisement, covered
> by AH. An SA
> > >        has to be set up between MN's CoA and the HA. How
> this is done
> > >        is out of scope, but MN and HA have some shared secret
> > > or can be
> > >        verified by some agent.
> > >
> > >        The Router Advertisement is returned by tunneling,
> as follows:
> > >
> > >           Outer src = HA's global address
> > >           Outer dst = care-of address
> > >           Outer src = HA's home subnet link-local address
> > >           Inner dst = all-nodes multicast address
> > >
> > >
> > >     7. Mobile node parses Router Advertisement and configures all
> > >        prefixes and addresses according to the method stated
> > > there.  If
> > >        the the M or O flags are set in the router
> > > advertisement, follow
> > >        the stateful (DHCPv6) configuration procedures.
> > >
> > >     8. Send binding update option(s) to establish
> bindings for the new
> > >        home addresses.
> > >
>


------_=_NextPart_000_01C04DBC.10870B50
Content-Type: application/octet-stream;
        name="Kay, Rodney.vcf"
Content-Disposition: attachment;
        filename="Kay, Rodney.vcf"

BEGIN:VCARD
VERSION:2.1
N:Kay;Rodney
FN:Kay, Rodney
ORG:Department of Veterans Affairs;VHA
TITLE:VistA Systems Manager
TEL;WORK;VOICE:(206)768-5482
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;Seattle VAMC;Puget Sound HC System=0D=0A1660 S. Columbian Way;Seattle;WA;98=
108-1597;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Seattle VAMC=0D=0APuget Sound HC System=0D=0A1660 S. Columbian Way=0D=0ASeat=
tle, WA 98108-1597=0D=0AUSA
EMAIL;PREF;INTERNET:Rodney.Kay@med.va.gov
REV:20000803T182959Z
END:VCARD

------_=_NextPart_000_01C04DBC.10870B50--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 13 19:49:54 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23631
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Nov 2000 19:49:54 -0500 (EST)
Received: from standards (47.234.32.16:4676) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB49DB@standards.nortelnetworks.com>; Mon, 13 Nov 2000 19:31:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 101197 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 19:31:34
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB49D9@standards.nortelnetworks.com>; Mon, 13 Nov 2000 19:31:34
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Mon, 13 Nov 2000 16:47:17 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <WZ7KDA8S>; Mon, 13 Nov 2000 16:33:48 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA81C9BB9@red-msg-06.redmond.corp.microsoft.com>
Date:         Mon, 13 Nov 2000 16:33:40 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Charlie Perkins <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> Aha, I just got why you want the Home Address before a
> Fragment header for firewalls: so they can see the Home
> Address in every packet even fragments. Duh. And the Fragment
> header has to be before the IPsec headers. Since ESP isn't
> friendly to firewalls anyway, firewall-friendliness is only a
> concern for AH. This means two header orders make sense:
> a) IPv6, Home Address, possible Fragment, AH, Binding Update,
> Transport
> b) IPv6, possible Fragment, ESP (auth and/or encryption),
> Home Address & Binding Update with CoA suboption, Transport

I've been thinking more about this "firewall friendliness" requirement that
is leading to a desire to put the Home Address option before the Fragment
header.

Don't most firewalls also want to look at the transport header, so they can
filter based on the ports? And of course the TCP or UDP header will only be
present in the offset-zero fragment. So I think conservative firewalls will
want to drop all fragments, whether or not the Home Address option is
accessible in the fragments.

On the other hand, suppose a firewall has a policy of dropping all
offset-zero fragments that are too small to contain a full transport header,
filtering offset-zero fragments that are big enough, and letting through all
other fragments. If the offset-zero fragment from a packet is dropped, the
remaining fragments will never be reassembled. At most they can cause a
minor DOS problem, but they can't be a vehicle for a security breakin. So
this liberal firewall actually would be safe, and it would have the
advantage of working with applications that fragment packets and still
allowing policies based on port numbers.

So I think with reasonable firewall design, there is no need to put the Home
Address option before the Fragment header. Either with conservative (drop
all fragments) firewalls, or liberal (let fragments through) firewalls,
having the Home Address available on non-offset-zero fragments doesn't
actually buy any added functionality.

Rich


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 13 21:37:22 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20165
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Nov 2000 21:37:22 -0500 (EST)
Received: from standards (47.234.32.16:3661) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4A5D@standards.nortelnetworks.com>; Mon, 13 Nov 2000 21:18:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 101373 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 21:18:39
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB4A5B@standards.nortelnetworks.com>; Mon, 13 Nov 2000 21:18:39
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA17342;
          Mon, 13 Nov 2000 18:35:09 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eAE2Z7711827; Mon, 13 Nov 2000 18:35:07
          -0800
X-Virus-Scanned:  Mon, 13 Nov 2000 18:35:07 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from Icharliep-1.iprg.nokia.com (205.226.22.18,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdiv3FiX; Mon, 13 Nov 2000
          18:35:03 PST
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <7695E2F6903F7A41961F8CF888D87EA81C9BB9@red-msg-06.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Charlie Perkins <charliep@IPRG.NOKIA.COM>
Message-ID:  <3A10A473.8FA94EBA@iprg.nokia.com>
Date:         Mon, 13 Nov 2000 18:33:24 -0800
Reply-To: Charlie Perkins <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Charlie Perkins <charliep@IPRG.nokia.com>
Organization: Nokia
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Richard Draves <richdr@microsoft.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Rich,

The sense I had gotten from previous discussion was that it
did in fact make sense for firewalls to exert some filtering
capability based on the home address.  This does make sense
to me.  I can well imagine that a firewall would have a hole
poked in it for a particular mobile node for a certain amount
of time.  I also understand that firewalls can be configured to
filter on more complicated rulesets, but that doesn't mean we
should disable abilities to use simpler rules.

However, I admit that I'm just following the conversation which
other people have been having.  I'm willing to follow whatever
consensus emerges.

More comments below...


> I've been thinking more about this "firewall friendliness" requirement that
> is leading to a desire to put the Home Address option before the Fragment
> header.
>
> Don't most firewalls also want to look at the transport header, so they can
> filter based on the ports? And of course the TCP or UDP header will only be
> present in the offset-zero fragment. So I think conservative firewalls will
> want to drop all fragments, whether or not the Home Address option is
> accessible in the fragments.
>
> On the other hand, suppose a firewall has a policy of dropping all
> offset-zero fragments that are too small to contain a full transport header,
> filtering offset-zero fragments that are big enough, and letting through all
> other fragments. If the offset-zero fragment from a packet is dropped, the
> remaining fragments will never be reassembled. At most they can cause a
> minor DOS problem, but they can't be a vehicle for a security breakin. So
> this liberal firewall actually would be safe, and it would have the
> advantage of working with applications that fragment packets and still
> allowing policies based on port numbers.

This would be bad.  An implementation of a rogue IPv6 could use
data from pretend fragments, and the firewall would not be performing
its filtering function.

> So I think with reasonable firewall design, there is no need to put the Home
> Address option before the Fragment header. Either with conservative (drop
> all fragments) firewalls, or liberal (let fragments through) firewalls,
> having the Home Address available on non-offset-zero fragments doesn't
> actually buy any added functionality.

Isn't fragmentation considered to be a useful piece of functionality?
I'm not comfortable just declaring by fiat that we should declare
fragments to be unimportant.  I'd rather make it possible to do the
right thing, so that firewall vendors can give it a try if the need is felt.

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 00:14:23 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29025
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 00:14:23 -0500 (EST)
Received: from standards (47.234.32.16:1307) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4BDF@standards.nortelnetworks.com>; Mon, 13 Nov 2000 23:55:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 101907 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 23:55:57
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB4BDD@standards.nortelnetworks.com>; Mon, 13 Nov 2000 23:55:56
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Mon, 13 Nov 2000 21:11:40 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <WZ7K1JT6>; Mon, 13 Nov 2000 21:12:26 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA80130C933@red-msg-06.redmond.corp.microsoft.com>
Date:         Mon, 13 Nov 2000 21:12:20 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] mobile IPv6 & IPsec policies
X-To:         "IPsec (E-mail)" <ipsec@lists.tislabs.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I had an old address for the ipsec list in my original email, so please
reply to this email instead.

-----Original Message-----
From: Richard Draves
Sent: Monday, November 13, 2000 9:06 PM
To: Mobile IP (E-mail); IPsec (E-mail)
Subject: mobile IPv6 & IPsec policies


I have some questions about the interactions between mobile IPv6 and IPsec
policy selection (SPD lookup) and IKE (SA negotiation) in
draft-ietf-mobileip-ipv6-12, especially sections 4.4 and 10.2. If this is
all obvious to others then perhaps the draft could be clarified. It's not
obvious to me and I don't know enough about IPsec & IKE to be certain of the
answers.

I believe the draft says/implies: the security policies on the mobile node
do not usually change when the mobile node moves, and policy lookups use
home addresses, not care-of addresses.

A. What policy selectors should be used when sending/receiving a Binding
Update? Section 10.2 says:

    -  As part of outbound packet processing in IP, the packet is
       compared against the IPsec Security Policy Database (SPD) to
       determine what processing is required for the packet [13].

    -  As a special case for Mobile IP, if a Binding Update or
       Binding Acknowledgement is being included in the packet, IPsec
       authentication, integrity protection, and replay protection MUST
       be applied to the packet [13, 11, 12], as defined in Section 4.4.
       If the SPD check above has already indicated that authentication
       and replay protection are required, this processing is sufficient
       for the Mobile IP requirement that all packets containing Binding
       Updates or Binding Acknowledgements be authenticated and covered
       by replay protection.  Otherwise, an implementation can force
       the required IPsec processing on this individual packet by, for
       example, creating a temporary SPD entry for the handling of this
       packet.

Suppose you are piggy-backing a Binding Update on a TCP or UDP packet, but
the selectors find a policy of "no IPsec needed" in the SPD. Then Mobile
IPv6 is saying, you should negotiate and use an SA anyway, because the
Binding Update needs to be protected. The suggestion is to create a
temporary SPD entry. What should this temporary SPD entry contain? What
transforms should be proposed in the ensuing IKE negotation? What if there
is a policy, but it doesn't provide the required protections - if you try to
negotiate an SA with IKE for transforms that aren't in the policy, isn't the
correspondent likely to reject the proposals when they don't match its
policy?

Suppose this is a "naked" Binding Update, not piggy-backed on a TCP or UDP
packet. What selectors should be used in the policy lookup? Should there be
a policy lookup at all, or should you instead try to find & use any suitable
existing SA between the two machines? It seems like a naked Binding Update
should reuse if possible an existing SA between the two machines.


B. Suppose the mobile node's home is in the same organization as the
correspondent node (ie normally no IPsec needed for communication between
home location & correspondent), but the mobile node is away from home. In
fact there is a Security Gateway between the mobile node and the
correspondent node, and the mobile node needs to use one SA to communicate
with the SG (say ESP tunnel-mode) and a second SA (say transport-mode AH) to
send binding-updates through to the correspondent node. A policy lookup on
the mobile node based solely on the home address will not work because the
result will be "no IPsec needed". Even if you force the use of IPsec to
protect the Binding Updates (as discussed above), you won't know to
negotiate a tunnel-mode SA and communicate via the SG.

One possibility (that I like) is that Mobile IPv6 effectively mandates that
policies that need communication via a security gateway must be implemented
in the routing table via a tunnel interface, instead of in the SPD. However,
mandating this style of implementation for security gateway policies would
be a departure from the base IPsec standard as I understand it. For one
thing, because routing table lookups are usually based just on destination
address and don't take into account the other IPsec selectors, this would
limit the kinds of policies that you could use.

An alternative would be to say the mobile node does TWO lookups in the SPD,
one using its home address and another using its care-of address, and merges
the resulting policies that it gets from those two lookups. Actually it gets
more complicated, because there might be an HA->CoA mapping for the
destination as well as the source address. The tunnel interface approach to
dealing with security gateways seems simpler.

Thanks,
Rich


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 00:23:04 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00953
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 00:23:04 -0500 (EST)
Received: from standards (47.234.32.16:1307) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4C13@standards.nortelnetworks.com>; Mon, 13 Nov 2000 23:58:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 101974 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 23:58:04
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB4C10@standards.nortelnetworks.com>; Mon, 13 Nov 2000 23:58:04
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Mon, 13 Nov 2000 21:05:30 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <WZ7K1JBV>; Mon, 13 Nov 2000 21:06:16 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA81C9BBA@red-msg-06.redmond.corp.microsoft.com>
Date:         Mon, 13 Nov 2000 21:06:10 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      [MOBILE-IP] mobile IPv6 & IPsec policies
X-To:         "IPsec (E-mail)" <ipsec@lists.tis.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I have some questions about the interactions between mobile IPv6 and IPsec
policy selection (SPD lookup) and IKE (SA negotiation) in
draft-ietf-mobileip-ipv6-12, especially sections 4.4 and 10.2. If this is
all obvious to others then perhaps the draft could be clarified. It's not
obvious to me and I don't know enough about IPsec & IKE to be certain of the
answers.

I believe the draft says/implies: the security policies on the mobile node
do not usually change when the mobile node moves, and policy lookups use
home addresses, not care-of addresses.

A. What policy selectors should be used when sending/receiving a Binding
Update? Section 10.2 says:

    -  As part of outbound packet processing in IP, the packet is
       compared against the IPsec Security Policy Database (SPD) to
       determine what processing is required for the packet [13].

    -  As a special case for Mobile IP, if a Binding Update or
       Binding Acknowledgement is being included in the packet, IPsec
       authentication, integrity protection, and replay protection MUST
       be applied to the packet [13, 11, 12], as defined in Section 4.4.
       If the SPD check above has already indicated that authentication
       and replay protection are required, this processing is sufficient
       for the Mobile IP requirement that all packets containing Binding
       Updates or Binding Acknowledgements be authenticated and covered
       by replay protection.  Otherwise, an implementation can force
       the required IPsec processing on this individual packet by, for
       example, creating a temporary SPD entry for the handling of this
       packet.

Suppose you are piggy-backing a Binding Update on a TCP or UDP packet, but
the selectors find a policy of "no IPsec needed" in the SPD. Then Mobile
IPv6 is saying, you should negotiate and use an SA anyway, because the
Binding Update needs to be protected. The suggestion is to create a
temporary SPD entry. What should this temporary SPD entry contain? What
transforms should be proposed in the ensuing IKE negotation? What if there
is a policy, but it doesn't provide the required protections - if you try to
negotiate an SA with IKE for transforms that aren't in the policy, isn't the
correspondent likely to reject the proposals when they don't match its
policy?

Suppose this is a "naked" Binding Update, not piggy-backed on a TCP or UDP
packet. What selectors should be used in the policy lookup? Should there be
a policy lookup at all, or should you instead try to find & use any suitable
existing SA between the two machines? It seems like a naked Binding Update
should reuse if possible an existing SA between the two machines.


B. Suppose the mobile node's home is in the same organization as the
correspondent node (ie normally no IPsec needed for communication between
home location & correspondent), but the mobile node is away from home. In
fact there is a Security Gateway between the mobile node and the
correspondent node, and the mobile node needs to use one SA to communicate
with the SG (say ESP tunnel-mode) and a second SA (say transport-mode AH) to
send binding-updates through to the correspondent node. A policy lookup on
the mobile node based solely on the home address will not work because the
result will be "no IPsec needed". Even if you force the use of IPsec to
protect the Binding Updates (as discussed above), you won't know to
negotiate a tunnel-mode SA and communicate via the SG.

One possibility (that I like) is that Mobile IPv6 effectively mandates that
policies that need communication via a security gateway must be implemented
in the routing table via a tunnel interface, instead of in the SPD. However,
mandating this style of implementation for security gateway policies would
be a departure from the base IPsec standard as I understand it. For one
thing, because routing table lookups are usually based just on destination
address and don't take into account the other IPsec selectors, this would
limit the kinds of policies that you could use.

An alternative would be to say the mobile node does TWO lookups in the SPD,
one using its home address and another using its care-of address, and merges
the resulting policies that it gets from those two lookups. Actually it gets
more complicated, because there might be an HA->CoA mapping for the
destination as well as the source address. The tunnel interface approach to
dealing with security gateways seems simpler.

Thanks,
Rich


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 00:45:04 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00956
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 00:23:04 -0500 (EST)
Received: from standards (47.234.32.16:1307) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4C83@standards.nortelnetworks.com>; Tue, 14 Nov 2000 0:00:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 102115 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 00:00:56
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB4C81@standards.nortelnetworks.com>; Tue, 14 Nov 2000 0:00:55
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Mon, 13 Nov 2000 21:16:39 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <WZ7K1KCQ>; Mon, 13 Nov 2000 21:17:25 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA80130C934@red-msg-06.redmond.corp.microsoft.com>
Date:         Mon, 13 Nov 2000 21:16:57 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Charlie Perkins <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> > On the other hand, suppose a firewall has a policy of dropping all
> > offset-zero fragments that are too small to contain a full
> transport header,
> > filtering offset-zero fragments that are big enough, and
> letting through all
> > other fragments. If the offset-zero fragment from a packet
> is dropped, the
> > remaining fragments will never be reassembled. At most they
> can cause a
> > minor DOS problem, but they can't be a vehicle for a
> security breakin. So
> > this liberal firewall actually would be safe, and it would have the
> > advantage of working with applications that fragment
> packets and still
> > allowing policies based on port numbers.
>
> This would be bad.  An implementation of a rogue IPv6 could use
> data from pretend fragments, and the firewall would not be performing
> its filtering function.

I don't understand. Are you supposing a rogue node *behind* the firewall?
Firewalls won't protect against that. Or are you supposing a node behind the
firewall is running a buggy IPv6 implementation, that manages to reassemble
& process a packet lacking the offset-zero fragment?

> > So I think with reasonable firewall design, there is no
> need to put the Home
> > Address option before the Fragment header. Either with
> conservative (drop
> > all fragments) firewalls, or liberal (let fragments
> through) firewalls,
> > having the Home Address available on non-offset-zero
> fragments doesn't
> > actually buy any added functionality.
>
> Isn't fragmentation considered to be a useful piece of functionality?
> I'm not comfortable just declaring by fiat that we should declare
> fragments to be unimportant.  I'd rather make it possible to do the
> right thing, so that firewall vendors can give it a try if
> the need is felt.

I wasn't saying that fragments are unimportant. I'm saying that you can be a
reasonable firewall and properly filter fragmented packets, without having
the Home Address (and transport header) in every fragment.

Rich


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 05:17:08 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10533
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 05:17:07 -0500 (EST)
Received: from standards (47.234.32.16:3297) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4F91@standards.nortelnetworks.com>; Tue, 14 Nov 2000 4:58:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 103088 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 04:58:23
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB4F8F@standards.nortelnetworks.com>; Tue, 14 Nov 2000 4:58:21
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAEAEfb15331; Tue, 14 Nov 2000 11:14:41 +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 LAA03309; Tue, 14 Nov 2000 11:14:40 +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.9.3/8.9.3) with
          ESMTP id LAA77773; Tue, 14 Nov 2000 11:16:42 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011141016.LAA77773@givry.rennes.enst-bretagne.fr>
Date:         Tue, 14 Nov 2000 11:16:42 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] mobile IPv6 & IPsec policies
X-To:         Richard Draves <richdr@microsoft.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Mon, 13 Nov 2000 21:06:10 PST. 
              <7695E2F6903F7A41961F8CF888D87EA81C9BBA@red-msg-06.redmond.corp.microsoft.com>

 In your previous mail you wrote:

   I have some questions about the interactions between mobile IPv6 and IPsec
   policy selection (SPD lookup) and IKE (SA negotiation) in
   draft-ietf-mobileip-ipv6-12, especially sections 4.4 and 10.2. If this is
   all obvious to others then perhaps the draft could be clarified. It's not
   obvious to me and I don't know enough about IPsec & IKE to be certain of the
   answers.

=> IPsec & IKE details are very implementation dependent...

   I believe the draft says/implies: the security policies on the mobile node
   do not usually change when the mobile node moves, and policy lookups use
   home addresses, not care-of addresses.

=> this is the idea.

   A. What policy selectors should be used when sending/receiving a Binding
   Update? Section 10.2 says:

       -  As part of outbound packet processing in IP, the packet is
          compared against the IPsec Security Policy Database (SPD) to
          determine what processing is required for the packet [13].

       -  As a special case for Mobile IP, if a Binding Update or
          Binding Acknowledgement is being included in the packet, IPsec
          authentication, integrity protection, and replay protection MUST
          be applied to the packet [13, 11, 12], as defined in Section 4.4.
          If the SPD check above has already indicated that authentication
          and replay protection are required, this processing is sufficient
          for the Mobile IP requirement that all packets containing Binding
          Updates or Binding Acknowledgements be authenticated and covered
          by replay protection.  Otherwise, an implementation can force
          the required IPsec processing on this individual packet by, for
          example, creating a temporary SPD entry for the handling of this
          packet.

   Suppose you are piggy-backing a Binding Update on a TCP or UDP packet, but
   the selectors find a policy of "no IPsec needed" in the SPD. Then Mobile
   IPv6 is saying, you should negotiate and use an SA anyway, because the
   Binding Update needs to be protected. The suggestion is to create a
   temporary SPD entry.

=> this is one option. Another one is to send the Binding Update alone...

   What should this temporary SPD entry contain? What
   transforms should be proposed in the ensuing IKE negotation? What if there
   is a policy, but it doesn't provide the required protections - if you try to
   negotiate an SA with IKE for transforms that aren't in the policy, isn't the
   correspondent likely to reject the proposals when they don't match its
   policy?

=> I believe if no SA is already available (ie. the temporary SPD entry
will call IKE) then it is far simpler to send the Binding Update (or
Acknowledge) in its own packet. But if the SPD processing can pick up
a SA then the temporary SPD entry can be a good solution...

   Suppose this is a "naked" Binding Update, not piggy-backed on a TCP or UDP
   packet. What selectors should be used in the policy lookup?

=> this is a different issue. I use the "protocol" 60 (destination option
header type) but of course this has to be understood by the peer.
An interoperable solution is to use the "any protocol" but this will
protect every packets (and solve both issues BTW).

   Should there be
   a policy lookup at all, or should you instead try to find & use any suitable
   existing SA between the two machines? It seems like a naked Binding Update
   should reuse if possible an existing SA between the two machines.

=> I agree but if you don't like to have a special processing because
of mobility you have to use the standard way (ie. SPD lookup, ...).

   B. Suppose the mobile node's home is in the same organization as the
   correspondent node (ie normally no IPsec needed for communication between
   home location & correspondent), but the mobile node is away from home. In
   fact there is a Security Gateway between the mobile node and the
   correspondent node, and the mobile node needs to use one SA to communicate
   with the SG (say ESP tunnel-mode) and a second SA (say transport-mode AH) to
   send binding-updates through to the correspondent node. A policy lookup on
   the mobile node based solely on the home address will not work because the
   result will be "no IPsec needed". Even if you force the use of IPsec to
   protect the Binding Updates (as discussed above), you won't know to
   negotiate a tunnel-mode SA and communicate via the SG.

=> this is SPD implementation dependent but I believe it should work
because it should be able to handle both protection/SPD entries for
the SG and for the correspondent...

   One possibility (that I like) is that Mobile IPv6 effectively mandates that
   policies that need communication via a security gateway must be implemented
   in the routing table via a tunnel interface, instead of in the SPD. However,
   mandating this style of implementation for security gateway policies would
   be a departure from the base IPsec standard as I understand it.

=> no but it is an implementation choice not yet understood (then without
consensus :-) by many IPsec folk.

   An alternative would be to say the mobile node does TWO lookups in the SPD,
   one using its home address and another using its care-of address, and merges
   the resulting policies that it gets from those two lookups.

=> if I have understood the problem is in the merge between the mobility
policy (with the correspondent) and the local/visit policy (use the SG).
If the second is not for the care-of address but for a wildcard address
(or the outgoing interface) then the merge seems possible (no conflict).
(my idea is the local/visit policy is a "situation" policy then the source
address is not the selector of choice)

   Actually it gets
   more complicated, because there might be an HA->CoA mapping for the
   destination as well as the source address.

=> for destination the things can be more transparent,

   The tunnel interface approach to
   dealing with security gateways seems simpler.

=> but are you ready to have link-local addresses for an IPsec tunnel
(ie. a SA in tunnel mode) ???

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 05:55:00 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22652
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 05:55:00 -0500 (EST)
Received: from standards (47.234.32.16:3008) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB500E@standards.nortelnetworks.com>; Tue, 14 Nov 2000 5:36:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 103255 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 05:36:36
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB500C@standards.nortelnetworks.com>; Tue, 14 Nov 2000 5:36:35
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAEAqhb25448; Tue, 14 Nov 2000 11:52:44 +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 LAA04703; Tue, 14 Nov 2000 11:52:43 +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.9.3/8.9.3) with
          ESMTP id LAA78049; Tue, 14 Nov 2000 11:54:43 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011141054.LAA78049@givry.rennes.enst-bretagne.fr>
Date:         Tue, 14 Nov 2000 11:54:42 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Richard Draves <richdr@microsoft.com>
X-cc:         Charlie Perkins <charliep@IPRG.nokia.com>,
              Francis Dupont <Francis.Dupont@inria.fr>,
              Vijay Devarapalli <vijayd@IPRG.nokia.com>,
              "mohan.parthasarathy" <Mohan.Parthasarathy@eng.sun.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Thu, 09 Nov 2000 21:54:09 PST. 
              <7695E2F6903F7A41961F8CF888D87EA8011AC2B1@red-msg-06.redmond.corp.microsoft.com>

 In your previous mail you wrote:

   RFC2401 compliant implementations find the correct security association
   based on the destination address, SPI, and IPsec header type.

=> and after each IPsec header processing they MUST check if the
source address matches the SA selector then the SA lookup is
not a valid argument.

   > This is a crucial point, and a decision should be made ASAP.
   >
   > There seem to be two additional relevant points:
   >
   > - We should pick a placement for the Home Address option,
   >    and make it mandatory.  Doing so will simplify the implementation
   >    for all the billions of correspondent nodes of the future.  We want
   >    that implementation to be as simple as possible.  The two
   >    candidate placements are either after ESP, possibly in the
   >    same options header as the Binding Update, or else before
   >    the Fragment Header.
   >
   > - Putting the information after ESP will make things substantially
   >    more complicated for possible firewall management.

   ESP might make firewall management more complicated, I won't dispute that.
   But my point is that users & admins should have a choice of using AH or ESP.

=> I read "or" not "either". AH and ESP have different properties then
different usage.

   In some environments, the appropriate choice might be ESP. In other
   environments, AH might be an appropriate choice.

=> and in some environments both are needed.

   If the Home Address option follows an AH header, a firewall can still find
   it easily.

=> this is not true for fragments.

   So if you want to be friendly to firewalls, have a policy of
   using AH. But please don't prevent others from using ESP.

=> we don't want to prevent others from using ESP, I believe there are
many cases with both AH and ESP. And this is a case where the "after ESP"
placement doesn't work.

   [Mohan]
   > As there is no real benefit in putting it after AH/ESP header, i would
   > suggest leaving it as it is i.e before AH/ESP header.

   There is real benefit. If you put the Home Address option after, then you
   can use either AH or ESP depending your policy/whim. If you put the Home
   Address option before, then you must use AH because ESP won't protect it.

=> but as you can use both then I can't see a problem here?

   So to summarize, I think the spec should say the Home Address option and the
   Binding Update option appear in the same destination options header, after
   the IPsec header(s),

=> this simply doesn't work if you have AH then ESP (then HA & BU) or
a paranoic IPsec implementation (which does the selector check at
lookup time, this is not in RFC 2401 but is very common).

   and if AH is not used, then the Binding Update must
   have a Care-Of Address suboption.

=> I agree, if the protection is not done by AH then there must be an
alternate care-of address suboption in order to protect the care-of.

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 06:03:23 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25370
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 06:03:22 -0500 (EST)
Received: from standards (47.234.32.16:3008) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB506C@standards.nortelnetworks.com>; Tue, 14 Nov 2000 5:44:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 103380 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 05:44:50
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB506A@standards.nortelnetworks.com>; Tue, 14 Nov 2000 5:44:50
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAEB1Ib34986; Tue, 14 Nov 2000 12:01:18 +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 MAA05020; Tue, 14 Nov 2000 12:01:17 +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.9.3/8.9.3) with
          ESMTP id MAA78099; Tue, 14 Nov 2000 12:03:20 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011141103.MAA78099@givry.rennes.enst-bretagne.fr>
Date:         Tue, 14 Nov 2000 12:03:20 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Richard Draves <richdr@microsoft.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Thu, 09 Nov 2000 22:49:36 PST. 
              <7695E2F6903F7A41961F8CF888D87EA8011AC2B3@red-msg-06.redmond.corp.microsoft.com>

 In your previous mail you wrote:

   Aha, I just got why you want the Home Address before a Fragment header for
   firewalls: so they can see the Home Address in every packet even fragments.

=> yes, for IPsec the Home Address MUST only be before the IPsec header(s).
The "before Fragment" is an unexpensive improvement for firewalls.

   Duh. And the Fragment header has to be before the IPsec headers. Since ESP
   isn't friendly to firewalls anyway, firewall-friendliness is only a concern
   for AH.

=> don't joke: this is not an argument! Mobile IPv6 is enough firewall
unfriend (because of its more than two addresses, for instance it makes
ingress filtering hairy) as it is.

 This means two header orders make sense:
   a) IPv6, Home Address, possible Fragment, AH, Binding Update, Transport
   b) IPv6, possible Fragment, ESP (auth and/or encryption), Home Address &
   Binding Update with CoA suboption, Transport

=> b) will fail with many IPsec implementations because the source address
will be wrong (ie. not the home address) at the SA selector check phase.
The easiest way to fix this is simply to mandate a).

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 06:10:24 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27640
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 06:10:24 -0500 (EST)
Received: from standards (47.234.32.16:3008) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB50B1@standards.nortelnetworks.com>; Tue, 14 Nov 2000 5:49:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 103469 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 05:49:42
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB50AF@standards.nortelnetworks.com>; Tue, 14 Nov 2000 5:49:42
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAEB5eb20451; Tue, 14 Nov 2000 12:05:41 +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 MAA05193; Tue, 14 Nov 2000 12:05:40 +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.9.3/8.9.3) with
          ESMTP id MAA78125; Tue, 14 Nov 2000 12:07:43 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011141107.MAA78125@givry.rennes.enst-bretagne.fr>
Date:         Tue, 14 Nov 2000 12:07:43 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         AIme Le-Rouzic <Aime.Le-Rouzic@bull.net>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Fri, 10 Nov 2000 09:22:50 +0100. 
              <3A0BB05A.1CEE621A@bull.net>

 In your previous mail you wrote:

    I don't think so, it needs to be friendly with firewalls  having a
   policy AH (for BU and BA) and having a policy ESP (for datas).For that
   the Home Address header has to be before the security header ESP to
   allow firewalls let the packet goes out or enter.

   We need to remember MobileIPv6 will be successful if it allows the user
   to protect its datas. The solution has to work when we have the two
   security headers in the packet AH +ESP. We need to offer the firewall to
   control them at least by the ip address.

=> in this context (ESP for data protection) the firewall will do
SPI filtering in place of ports filtering (with the suitable policy
both are equivalent, of course this supposes some firewall and IPsec
colaboration but this is the way to make ESP firewall-friendly).

Thanks

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 06:15:16 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29185
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 06:15:15 -0500 (EST)
Received: from standards (47.234.32.16:3008) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5109@standards.nortelnetworks.com>; Tue, 14 Nov 2000 5:56:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 103585 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 05:56:39
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB5107@standards.nortelnetworks.com>; Tue, 14 Nov 2000 5:56:39
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAEBD7b37692; Tue, 14 Nov 2000 12:13:07 +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 MAA05440; Tue, 14 Nov 2000 12:13:07 +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.9.3/8.9.3) with
          ESMTP id MAA78180; Tue, 14 Nov 2000 12:15:10 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011141115.MAA78180@givry.rennes.enst-bretagne.fr>
Date:         Tue, 14 Nov 2000 12:15:10 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Fri, 10 Nov 2000 10:48:05 PST. 
              <200011101848.eAAIm5F16514@locked.eng.sun.com>

 In your previous mail you wrote:

   Home Address option - a destination option can appear anywhere
   and it is not really a destination option anymore :-) Does this
   mean RFC2460 needs an update where the recommended order makes
   no more sense (Tunnel encapsualtion limit already broke this
   some time back).

=> I *agree*. At the ETSI bake-off discussion many of them asked for
a simplification (destination option header processing is a nightmare).
I already explained my proposal but I *never* got an answer from
an IPv6 person... Can you bring this point to the IPng WG list?

Thanks

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 06:27:24 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03109
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 06:27:24 -0500 (EST)
Received: from standards (47.234.32.16:3008) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5171@standards.nortelnetworks.com>; Tue, 14 Nov 2000 6:08:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 103722 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 06:08:54
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB516F@standards.nortelnetworks.com>; Tue, 14 Nov 2000 6:08:54
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAEBPDb37807; Tue, 14 Nov 2000 12:25:13 +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 MAA05824; Tue, 14 Nov 2000 12:25:12 +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.9.3/8.9.3) with
          ESMTP id MAA78247; Tue, 14 Nov 2000 12:27:15 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011141127.MAA78247@givry.rennes.enst-bretagne.fr>
Date:         Tue, 14 Nov 2000 12:27:15 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Richard Draves <richdr@microsoft.com>
X-cc:         Charlie Perkins <charliep@iprg.nokia.com>,
              Francis Dupont <Francis.Dupont@inria.fr>,
              Vijay Devarapalli <vijayd@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Fri, 10 Nov 2000 12:09:16 PST. 
              <7695E2F6903F7A41961F8CF888D87EA80130C8FE@red-msg-06.redmond.corp.microsoft.com>

 In your previous mail you wrote:

   > I have looked at 4 free implementations:
   >  - all of them don't use the source address for the SA lookup
   >  - two of them do the check of the source address at the end of
   >    the SA lookup then the source address must be available (ie.
   >    the header with the home address option must be before the first
   >    IPsec header)
   >  - only one of them don't check the source address after the
   > processing
   >    of a IPsec header in transport mode
   > Conclusion: if the home address is not available after the processing
   > of *each* IPsec header then we'll kill near all IPsec implementations
   > (ie. someone will say we'll kill all compliant implementations), if
   > it is not available before any IPsec header then we'll kill
   > all paranoic
   > implementations (at least one half IMHO).

   There are implementations for which this conclusion is not true.

=> yes, the point is how to interpret the RFC 2401 and to look at current
implementations seems a good way to know past interpretations (including
one by the author of the RFC).

   I think the best approach is to figure out what is the right thing for the
   protocol, and then implementors should implement it.

=> I agree but this is true only for the mobile IPv6 part, not the IPv6
or IPsec parts even we can complain they are not perfect (enough).

   Your approach seems to
   be to look at what a few particular implementations do and then base the
   protocol on that.

=> I just like to understand what is the current practice for SA selector
checks because the RFC 2401 is not very clear (at least no enough to avoid
this discussion). The conclusion is a strict interpretation is valid
(and they are even stricter interpretations in the real world) then
anything based on a loose interpretation will fail.

   Seems backwards.

=> do you prefer to lose some months in the IPsec mailing list to clarify
in your way the RFC 2401 and then to modify a large part of current IPsec
implementations? I don't think so.

Regards

Francis.Dupont@enst-bretagne.fr

PS: I don't believe nothing should be done but there is a working solution
today then we should adopt it *now* and keep the door open.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 07:50:05 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03220
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 07:50:04 -0500 (EST)
Received: from standards (47.234.32.16:3057) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5211@standards.nortelnetworks.com>; Tue, 14 Nov 2000 7:31:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 103938 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 07:31:41
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB520F@standards.nortelnetworks.com>; Tue, 14 Nov 2000 7:31:41
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAECm4b36006; Tue, 14 Nov 2000 13:48:04 +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 NAA08874; Tue, 14 Nov 2000 13:48:03 +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.9.3/8.9.3) with
          ESMTP id NAA78518; Tue, 14 Nov 2000 13:50:06 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011141250.NAA78518@givry.rennes.enst-bretagne.fr>
Date:         Tue, 14 Nov 2000 13:50:05 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Richard Draves <richdr@microsoft.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Mon, 13 Nov 2000 21:16:57 PST. 
              <7695E2F6903F7A41961F8CF888D87EA80130C934@red-msg-06.redmond.corp.microsoft.com>

 In your previous mail you wrote:

   I wasn't saying that fragments are unimportant. I'm saying that you can be a
   reasonable firewall and properly filter fragmented packets, without having
   the Home Address (and transport header) in every fragment.

=> I am not a firewall person (in fact, I don't like firewalls) but
this (the before fragment) was asked by firewall people and it is
cheap to give to them then IMHO we should do what firewall people want.

Regards

Francis.Dupont@enst-bretagne.fr

PS: tunnel encapsulation limit is different because it is useful
(ie. it makes sense) only if it is carried by every fragments.
This is a stronger argument in favor of the "before fragment" placement.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 08:01:59 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07316
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 08:01:58 -0500 (EST)
Received: from standards (47.234.32.16:3057) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5261@standards.nortelnetworks.com>; Tue, 14 Nov 2000 7:43:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 104046 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 07:43:34
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB525F@standards.nortelnetworks.com>; Tue, 14 Nov 2000 7:43:34
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAECxmb36980; Tue, 14 Nov 2000 13:59:50 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr
          [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with
          ESMTP id NAA09352; Tue, 14 Nov 2000 13:59:47 +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.9.3/8.9.3) with
          ESMTP id OAA78614; Tue, 14 Nov 2000 14:01:48 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011141301.OAA78614@givry.rennes.enst-bretagne.fr>
Date:         Tue, 14 Nov 2000 14:01:48 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] DAD
X-To:         "Powell, Ken" <Ken.Powell@compaq.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Thu, 09 Nov 2000 13:54:51 EST. 
              <C99A689B0CB9D111AF3F0000F8062CCD08FB83BF@zkoexc2.zko.dec.com>

 In your previous mail you wrote:

     The home agent will only defend against a duplicate
     address when there is a binding with the mobile node.
     Therefore, the mobile node MUST treat creation of a
     new binding with the home agent using an existing home
     address the same as creation of a new home address.

=> I can't see the difference between this and the current spec.

   > On page 22, the current specification says:
   >
   >          ...      The mobile node SHOULD set the Duplicate Address
   >          Detection (D) bit based on any requirements for Duplicate
   >          Address Detection that would apply to the mobile node if it
   >          were at home [17, 27].

=> when a node is attached again to a link with an existing address
(this can imply static configuration which is used for routers for instance)
then it should perform a DAD. For a mobile node this gives the "new binding
using an existing home address", doesn't this?

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 08:23:38 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14836
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 08:23:37 -0500 (EST)
Received: from standards (47.234.32.16:3057) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB52BE@standards.nortelnetworks.com>; Tue, 14 Nov 2000 8:05:19 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 104168 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 08:05:18
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB52BC@standards.nortelnetworks.com>; Tue, 14 Nov 2000 8:05:17
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAEDLjb37243; Tue, 14 Nov 2000 14:21: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 OAA10251; Tue, 14 Nov 2000 14:21: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.9.3/8.9.3) with
          ESMTP id OAA78764; Tue, 14 Nov 2000 14:23:48 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011141323.OAA78764@givry.rennes.enst-bretagne.fr>
Date:         Tue, 14 Nov 2000 14:23:48 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] Binding Cache entries per IPv6 address at Corresp
              ondent Node
X-To:         Richard Draves <richdr@microsoft.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Thu, 09 Nov 2000 22:40:13 PST. 
              <7695E2F6903F7A41961F8CF888D87EA8011AC2B2@red-msg-06.redmond.corp.microsoft.com>

 In your previous mail you wrote:

   > > A CN/HA with more than one interface address may get independent BUs
   > > sent to it...

   This is an interesting problem! First let me confirm: my understanding is
   that a MN can only have a single mapping from HA to CoA, because it can send
   its home agent a single such binding. In particular, a MN can not reasonably
   use one CoA when talking to one correspondent and a different CoA when
   talking to a different correspondent.

=> a MN can use several different CoAs at the same time. The issue is
it can't know if two addresses belong to the same node then the mapping
must deal with the correspondent address too (mainly because of sequence
numbers which have *no* reason to match, CoA stuff is for the fun :-).

   Previously the Binding Cache Entry maintained a mapping HA -> CoA. Your
   suggested solution means that now the Binding Cache Entry is effectively a
   triple, besides the HA & CoA there is also the correspondent address CA. The
   mapping is (CA, HA) -> CoA. So when the correspondent looks up a Binding
   Cache Entry, it finds one with the right CA (source address) and HA
   (original destination) and gets the mapping to a CoA.

=> exactly. In fact the correspondent can ignore the CA in lookups for
an outgoing packet but it can't ignore it for the binding cache management.

   This means that if the correspondent sends a packet to the mobile using a
   new CA2, then it might not find a Binding Cache Entry (and the packet will
   be routed via the home agent), even if it has a Binding Cache Entry for CA1.

=> yes, this scenario is possible.

   (There are scenarios involving anycast where this would be common.)

=> anycast source addresses?

   One solution would be to say, although there may be multiple Binding Cache
   Entries for a HA -> CoA mapping, one per CA (to track the sequence numbers
   properly), when looking up a Binding Cache Entry you can find & use any of
   them regardless of the packet's source address.

=> it depends what is the purpose of the lookup. I agree the source address
(CA) is only useful for the binding cache management. Have you a proposal
for this nuance?

   Another solution (pretty much equivalent but conceptualized differently)
   would be to say, there is one Binding Cache Entry for the mapping HA -> CoA,
   but the single Binding Cache Entry can contain a sequence number per CA.
   (I'm not sure if the binding lifetime needs to be per CA or not.)

=> the binding lifetime is per CA because the MN doesn't know the list
of the CN addresses.
As an implementor I prefer to add a CA field in the Binding Cache Entry,
this gives the same result but perhaps this is easier to explain.

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 08:44:33 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19952
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 08:44:33 -0500 (EST)
Received: from standards (47.234.32.16:3057) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB531D@standards.nortelnetworks.com>; Tue, 14 Nov 2000 8:26:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 104290 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 08:26:08
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB531B@standards.nortelnetworks.com>; Tue, 14 Nov 2000 8:26:07
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAEDgUb29385; Tue, 14 Nov 2000 14:42:30 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr
          [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with
          ESMTP id OAA11016; Tue, 14 Nov 2000 14:42:30 +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.9.3/8.9.3) with
          ESMTP id OAA78911; Tue, 14 Nov 2000 14:44:33 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011141344.OAA78911@givry.rennes.enst-bretagne.fr>
Date:         Tue, 14 Nov 2000 14:44:33 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      [MOBILE-IP]
X-To:         "Powell, Ken" <Ken.Powell@compaq.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Thu, 09 Nov 2000 17:01:55 EST. 
              <C99A689B0CB9D111AF3F0000F8062CCD08FB83C2@zkoexc2.zko.dec.com>

 In your previous mail you wrote:

   I did a quick comparison to RFC 2460 and the latest Advanced
   IPv6 API spec. RFC 2460 recommends the header order listed
   below:

=> the RFC 2460 has a clear problem with destination option headers.

      IPv6 header

      Hop-by-Hop Options

      Destination Options (AdvAPI: only if routing header exists)

=> these destination options are for intermediate hops listed in
the routing header. No such destination option is defined today.

      Routing
           <--- Charlie: destination option w/ home address here
      Fragment

      Authentication

      Encapsulating Security Payload

=> insert possible IP compression header here.

      Destination Options <--- Charlie: binding update here

=> this is the standard destination option placement but it doesn't
work for home address or tunnel encapsulation limit, only for others
which are binding update, acknowledgement and request.

      upper-layer

   The advanced API spec currently only allows for 2 destination
   option headers.

=> the advanded API is RFC 2460 compliant (:-).

   I was wondering why create another destination option header
   for the home address option after the routing header instead
   using the existing one before?

=> because the purpose is not the same.

   On the other hand, I
   don't know why RFC 2460 put the destination option header
   before the routing header.

=> by mistake? Seriously the destination option stuff must be revisited
because it is too hairy (even two different kinds of options are too many).

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 10:23:13 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20087
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 10:23:12 -0500 (EST)
Received: from standards (47.234.32.16:4659) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB53DC@standards.nortelnetworks.com>; Tue, 14 Nov 2000 10:04:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 104542 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 10:04:29
          -0500
Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB53DA@standards.nortelnetworks.com>; Tue, 14 Nov 2000 10:04:28
          -0500
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA05206 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 14 Nov 2000 08:21:00
          -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116])
          by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA28234 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 14 Nov 2000 08:21:00
          -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2651.58) id
          <WSGVJRGD>; Tue, 14 Nov 2000 09:21:00 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain
Approved-By:  Roberts Philip-qa3445 <Philip_Roberts-qa3445@EMAIL.MOT.COM>
Message-ID:  <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D281@il27exm03.cig.mot.com>
Date:         Tue, 14 Nov 2000 09:20:56 -0600
Reply-To: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Subject:      [MOBILE-IP] new I-Ds
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Just a reminder that Friday is the deadline for submitting new -00 drafts
for consideration.

Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 11:24:17 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08803
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 11:24:17 -0500 (EST)
Received: from standards (47.234.32.16:4659) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB548C@standards.nortelnetworks.com>; Tue, 14 Nov 2000 11:05:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 104772 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 11:05:40
          -0500
Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB548A@standards.nortelnetworks.com>; Tue, 14 Nov 2000 11:05:39
          -0500
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA28114 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 14 Nov 2000 09:22:11
          -0700 (MST)]
Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102])
          by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA08850 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 14 Nov 2000 09:22:11
          -0700 (MST)]
Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id
          <WMS1AL7J>; Tue, 14 Nov 2000 10:22:10 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain
Approved-By:  Roberts Philip-qa3445 <Philip_Roberts-qa3445@EMAIL.MOT.COM>
Message-ID:  <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D284@il27exm03.cig.mot.com>
Date:         Tue, 14 Nov 2000 10:22:03 -0600
Reply-To: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Subject:      [MOBILE-IP] requests received
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi folks,

        here are the requests we've received thus far for the San Diego meeting.  Please double check that we've got your requests.  Order doesn't imply anything.  Please note we've got requests for about 4 hours of presentations already and listing a request does not mean you will get an agenda slot.  We'll do our best to accomodate as many as possible.

Phil


Vijay Devarapali        5       MIPv6 ETSI Bake-off Report
Glenn Morrow            30      Intercepting Location Updates           draft-lmk-mobileip-intercepting-update-00.txt
Samita Chakrabarti      10      Reverse tunneling implementation details        draft-ietf-mobileip-rfc2344-bis-03.txt
Hesham Soliman  5       Draft update    draft-ietf-mobileip-rfc2344-bis-02.txt
Hesham Soliman  10      Route optimization in v6
Hesham Soliman  10                      draft-soliman-l2api-00
Hesham Soliman  10      Fast Handoff    draft-elmalki-mobileip-fast-handoffs-03.txt
Steve Glass             20      Use of DHCP in Mobile IP        draft-glass-mobileip-agent-dhcp-proxy-00.txt
Steve Glass             15      Registration Revocation for Mobile IP   draft-glass-mobileip-reg-revok-00.txt
Behcet Sarikaya 5       Mobile IPv6 Regional Paging
Pat Calhoun             10      proactive handoff       draft-calhoun-mobileip-proactive-fa-02.txt
Charlie Perkins 10      MIPv6 update            draft-ietf-mobileip-ipv6-12.txt
Charlie Perkins 10      AAAv6 for MIP
Charlie Perkins 10      DIAMETER extensions for MIP     draft-calhoun-diameter-mobileip-11.txt
Charlie Perkins 10      IP v6 Regional Registration Draft       draft-malinen-mobileip-regreg6-00.txt
Charlie Perkins 10      v6 fast handover team
Archan Misra            10      Interdomain Mobility Management Protocol        draft-misra-mobileip-idmp-00.txt
Rajeev Koodli           10      v6 fast handoff draft-koodli-mobileip-fastv6-0x.txt
Jiwoong Lee             6       SGM support in MIP      draft-lee-sgm-support-mobileip-00.txt
Ernst Thierry           10      Mobile Network Support  draft-lee-sgm-support-mobileip-00.txt
SL Tsao         15      Introducing Mobile IP in IPv4/IPv6 Interconnected networks                                      draft-tsao-mobileip-duelstack-model-00.txt
Samita Chakrabarti      10      Private addressing      draft-ietf-mobileip-rfc2344-bis
Jari Malinen            5       GSM SIM authentication  draft-haverinen-mobileip-gsmsim-00.txt
Pekka Nikander  10      Mobile IP v6 for the Homeless   draft-nikander-mobileip-homelessv6-00.txt


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 11:35:07 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11553
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 11:35:07 -0500 (EST)
Received: from standards (47.234.32.16:4659) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB54E2@standards.nortelnetworks.com>; Tue, 14 Nov 2000 11:16:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 104886 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 11:16:38
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBB54E0@standards.nortelnetworks.com>;
          Tue, 14 Nov 2000 11:16:37 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id JAA25902; Tue, 14 Nov 2000 09:33:08
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          IAA27895; Tue, 14 Nov 2000 08:33:04 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id IAA06578; Tue, 14 Nov 2000 08:33:03
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Patrice Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.974219417.19223.pcalhoun@nasnfs>
Date:         Tue, 14 Nov 2000 08:30:17 -0800
Reply-To: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] requests received
X-To:         Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D284@il27exm03.cig.mot.com>

> Please note we've got requests for about 4 hours of presentations already
and  > listing a request does not mean you will get an agenda slot.  We'll do
our best  > to accomodate as many as possible.

May I recommend that you accept discussions based on items that fit within the
current charter, and perhaps even prioritize based on what is most urgent to
complete (e.g. milestones whose deadline is quickly approaching).

Although I see plenty of great work being presented, it seems like we should
concentrate on completing our milestones. New work should get small amount of
time only (e.g. 2-3 minutes). People can always go off and read the I-Ds, so
an introduction of the concept should be more than sufficient.

Of course, we should also save a little time figure out how we are doing with
our current milestones, and perhaps adjust them if need be.

My 2 cents,

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 11:42:08 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13863
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 11:42:08 -0500 (EST)
Received: from standards (47.234.32.16:4659) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB553B@standards.nortelnetworks.com>; Tue, 14 Nov 2000 11:25:00 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 105003 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 11:25:00
          -0500
Received: from motgate3.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB5539@standards.nortelnetworks.com>; Tue, 14 Nov 2000 11:24:55
          -0500
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          motgate3.mot.com (motgate3 2.1) with ESMTP id JAA05748 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 14 Nov 2000 09:38:16
          -0700 (MST)]
Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102])
          by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA24396 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 14 Nov 2000 09:41:26
          -0700 (MST)]
Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id
          <WMS1AMRQ>; Tue, 14 Nov 2000 10:41:25 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain
Approved-By:  Roberts Philip-qa3445 <Philip_Roberts-qa3445@EMAIL.MOT.COM>
Message-ID:  <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D286@il27exm03.cig.mot.com>
Date:         Tue, 14 Nov 2000 10:41:22 -0600
Reply-To: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Subject:      Re: [MOBILE-IP] requests received
X-To:         Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

You may recommend it indeed.

This is the plan for structuring an agenda.  Hopefully we'll have a draft agenda out for comment before too much longer.


> ----------
> From:         Patrice Calhoun
> Reply To:     Patrice Calhoun
> Sent:         Wednesday, November 15, 2000 12:30 AM
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: [MOBILE-IP] requests received
>
> > Please note we've got requests for about 4 hours of presentations already
> and  > listing a request does not mean you will get an agenda slot.  We'll do
> our best  > to accomodate as many as possible.
>
> May I recommend that you accept discussions based on items that fit within the
> current charter, and perhaps even prioritize based on what is most urgent to
> complete (e.g. milestones whose deadline is quickly approaching).
>
> Although I see plenty of great work being presented, it seems like we should
> concentrate on completing our milestones. New work should get small amount of
> time only (e.g. 2-3 minutes). People can always go off and read the I-Ds, so
> an introduction of the concept should be more than sufficient.
>
> Of course, we should also save a little time figure out how we are doing with
> our current milestones, and perhaps adjust them if need be.
>
> My 2 cents,
>
> PatC
>
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 11:52:44 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16838
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 11:52:43 -0500 (EST)
Received: from standards (47.234.32.16:4659) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB554E@standards.nortelnetworks.com>; Tue, 14 Nov 2000 11:26:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 105023 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 11:26:41
          -0500
Received: from mgw-dax2.ext.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB554A@standards.nortelnetworks.com>; Tue, 14 Nov 2000 11:26:41
          -0500
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 eAEGhK627192 for
          <MOBILE-IP@standards.nortelnetworks.com>; Tue, 14 Nov 2000 10:43:30
          -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by
          davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.1.5)
          with ESMTP id <Tac12f2574fdf2b6619@davir04nok.americas.nokia.com>;
          Tue, 14 Nov 2000 10:42:59 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <WZZB35RY>;
          Tue, 14 Nov 2000 10:38:54 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  Basavaraj.Patil@NOKIA.COM
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E5BB@daeis07nok>
Date:         Tue, 14 Nov 2000 10:39:09 -0600
Reply-To: Basavaraj.Patil@nokia.com
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Basavaraj Patil <Basavaraj.Patil@nokia.com>
Subject:      Re: [MOBILE-IP] requests received
X-To:         Pat.Calhoun@Eng.Sun.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Pat,

Phil's note was just to indicate the current requests received. Obviously
not all will be on the agenda.

-Basavaraj

> -----Original Message-----
> From: EXT Patrice Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM]
> Sent: Tuesday, November 14, 2000 10:30 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] requests received
>
>
> > Please note we've got requests for about 4 hours of
> presentations already
> and  > listing a request does not mean you will get an agenda
> slot.  We'll do
> our best  > to accomodate as many as possible.
>
> May I recommend that you accept discussions based on items
> that fit within the
> current charter, and perhaps even prioritize based on what is
> most urgent to
> complete (e.g. milestones whose deadline is quickly approaching).
>
> Although I see plenty of great work being presented, it seems
> like we should
> concentrate on completing our milestones. New work should get
> small amount of
> time only (e.g. 2-3 minutes). People can always go off and
> read the I-Ds, so
> an introduction of the concept should be more than sufficient.
>
> Of course, we should also save a little time figure out how
> we are doing with
> our current milestones, and perhaps adjust them if need be.
>
> My 2 cents,
>
> PatC
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 14 12:43:36 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29276
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Nov 2000 12:43:35 -0500 (EST)
Received: from standards (47.234.32.16:4659) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB564E@standards.nortelnetworks.com>; Tue, 14 Nov 2000 12:24:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 105367 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 12:24:57
          -0500
Received: from zmamail04.zma.compaq.com (mailout.zma.compaq.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB564C@standards.nortelnetworks.com>; Tue, 14 Nov 2000
          12:24:57 -0500
Received: by zmamail04.zma.compaq.com (Postfix,
          from userid 12345) id D4CAD704; Tue, 14 Nov 2000 12:41:27 -0500 (EST)
Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net
          [16.103.129.42]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id
          CB7C0216; Tue, 14 Nov 2000 12:41:27 -0500 (EST)
Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service
          (5.5.2652.78) id <W5QBNBL6>; Tue, 14 Nov 2000 12:41:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Powell, Ken" <Ken.Powell@COMPAQ.COM>
Message-ID:  <C99A689B0CB9D111AF3F0000F8062CCD08FB83CF@zkoexc2.zko.dec.com>
Date:         Tue, 14 Nov 2000 12:41:20 -0500
Reply-To: "Powell, Ken" <Ken.Powell@compaq.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Powell, Ken" <Ken.Powell@compaq.com>
Subject:      Re: [MOBILE-IP] DAD
X-To:         Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

A node normally runs DAD only when creating a new address when
attached directly to its home subnet. The specific case that
was of concern occurs when a binding is dropped for a valid
address on the home network that already passed DAD. When the
binding gets re-created, the mobile node does not create a new
address, it reuses the old one. I believe the spec was ambiguous
in that its not clear how to apply the rules for running DAD in
this situation. The mobile ipv6 spec didn't say anything special.

I tracked down the applicable statement in RFC 2462 section 5.4
on when DAD should be run.

   Duplicate Address Detection is performed on unicast addresses prior
   to assigning them to an interface whose DupAddrDetectTransmits
   variable is greater than zero. Duplicate Address Detection MUST take
   place on all unicast addresses, regardless of whether they are
   obtained through stateful, stateless or manual configuration,...

   <snip>

   It should also be noted that Duplicate Address Detection must be
   performed prior to assigning an address to an interface in order to
   prevent multiple nodes from using the same address simultaneously.

I think the definition of what it means to assign an address to
an interface is a bit fuzzy with mobility. I see no harm in
clarifying the rules on how home address bindings, or lack
thereof, impact DAD.

Ken

> -----Original Message-----
> From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr]
> Sent: Tuesday, November 14, 2000 8:02 AM
> To: Powell, Ken
> Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] DAD
>
>
>  In your previous mail you wrote:
>
>      The home agent will only defend against a duplicate
>      address when there is a binding with the mobile node.
>      Therefore, the mobile node MUST treat creation of a
>      new binding with the home agent using an existing home
>      address the same as creation of a new home address.
>
> => I can't see the difference between this and the current spec.
>
>    > On page 22, the current specification says:
>    >
>    >          ...      The mobile node SHOULD set the
> Duplicate Address
>    >          Detection (D) bit based on any requirements for
> Duplicate
>    >          Address Detection that would apply to the
> mobile node if it
>    >          were at home [17, 27].
>
> => when a node is attached again to a link with an existing address
> (this can imply static configuration which is used for
> routers for instance)
> then it should perform a DAD. For a mobile node this gives
> the "new binding
> using an existing home address", doesn't this?
>
> Regards
>
> Francis.Dupont@enst-bretagne.fr
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov 15 02:58:20 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20837
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 15 Nov 2000 02:58:19 -0500 (EST)
Received: from standards (47.234.32.16:3395) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB597A@standards.nortelnetworks.com>; Wed, 15 Nov 2000 2:39:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 106449 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Nov 2000 02:39:35
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB5978@standards.nortelnetworks.com>; Wed, 15 Nov 2000 2:39:34
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAF7tsb29036; Wed, 15 Nov 2000 08:55:55 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr
          [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with
          ESMTP id IAA15119; Wed, 15 Nov 2000 08:55: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.9.3/8.9.3) with
          ESMTP id IAA82899; Wed, 15 Nov 2000 08:58:00 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011150758.IAA82899@givry.rennes.enst-bretagne.fr>
Date:         Wed, 15 Nov 2000 08:58:00 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] DAD
X-To:         "Powell, Ken" <Ken.Powell@compaq.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Tue, 14 Nov 2000 12:41:20 EST. 
              <C99A689B0CB9D111AF3F0000F8062CCD08FB83CF@zkoexc2.zko.dec.com>

 In your previous mail you wrote:

   A node normally runs DAD only when creating a new address when
   attached directly to its home subnet. The specific case that
   was of concern occurs when a binding is dropped for a valid
   address on the home network that already passed DAD. When the
   binding gets re-created, the mobile node does not create a new
   address, it reuses the old one.

=> for me to re-creat a binding or to re-assign an address to an interface
is the same thing. The re- is covered by the manual configuration case
(which is a common way to re-use the same address in the RFC 2462 context).
But the question is: this is obvious or this needs clarification?

   I think the definition of what it means to assign an address to
   an interface is a bit fuzzy with mobility.

=> perhaps this is the point which needs clarification. I believe
for a mobile node to assign an address to an interface attached to
the home link or to perform a new home registration (ie. to create
a new binding with a home agent, new is relative to the home address
not the care-of) are the same thing.

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov 15 08:35:36 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23879
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 15 Nov 2000 08:35:36 -0500 (EST)
Received: from standards (47.234.32.16:4386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5B00@standards.nortelnetworks.com>; Wed, 15 Nov 2000 8:17:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 106950 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Nov 2000 08:17:02
          -0500
Received: from RRMAIL01.RADIOROUTER_NT (63.103.94.23:3592) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB5AFE@standards.nortelnetworks.com>; Wed, 15 Nov 2000
          8:17:01 -0500
Received: by servicepackcentral.com with Internet Mail Service (5.5.2650.21) id
          <V8NKYRXN>; Wed, 15 Nov 2000 08:33:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  George Tsirtsis <G.Tsirtsis@FLARION.COM>
Message-ID:  <D0BFB433B390D411A6B500B0D07C53A10205DA@freeairmail.com>
Date:         Wed, 15 Nov 2000 08:33:35 -0500
Reply-To: George Tsirtsis <G.Tsirtsis@flarion.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: George Tsirtsis <G.Tsirtsis@flarion.com>
Subject:      Re: [MOBILE-IP] v4 fast handoff lack of interest?
X-cc:         Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>,
              "mscorson@ix.netcom.com" <mscorson@ix.netcom.com>,
              "Philip_Roberts-qa3445@email.mot.com"
              <Philip_Roberts-qa3445@email.mot.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

All,

I am a bit surprised that none of the 7 authors of the FA assisted proposal
has reacted to this e-mail. Raj was worried that the WG did not care but
maybe not even the authors of this proposal care.
...just joking ;-)

Seriously, unless we have some debate on this, how do we expect to resolve
this issue in the meeting?

Regards
George
-----Original Message-----
From: Patrice Calhoun
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Sent: 11/8/00 12:07 PM
Subject: Re: [MOBILE-IP] v4 fast handoff lack of interest?

> > We do, however, feel that the FA assisted proposal can be improved.
> >
Speaking as one of the co-authors of the draft (but I presume that all
authors
would agree with me), providing some command and/or improvements to the
I-D
would be most appreciated. I will read your comments a little later and
provide my input.

Thanks,

PatC


-----Original Message-----
From: M. Scott Corson
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Sent: 11/8/00 11:47 AM
Subject: Re: [MOBILE-IP] v4 fast handoff lack of interest?

..
Phil,

Just on time we have some comments.....and you thought that no one cared
:-)

We feel that the FA assisted approach has a number of advantages over
the
fast handoff approach. Most of the arguments, however, have been made
already in this list (see McCann's "[MOBILE-IP] Differences between the
two
MIPv4 handoff approaches" for an example). The most important arguments
against Fast Handoff from our point of view is:
1. Increased signaling on the old link; which might be degrading.
2. Ability of the FA assisted approach to support vanilla RFC2002 MIP
clients.

We do, however, feel that the FA assisted proposal can be improved.

Please consider the following modifications:
Lets use the basic idea of Source and Destination Trigger but also
support
the following:
1. A temporary tunnel between old FA and new FA (whether GFA/AFA is used
or
not)
2. The creation of this temporary tunnel to be based on BR/BU/BUAck
messages (see below)
3. Regional/Hierarchical mobile IP signaling to be optionally used in
parallel to the 1,2

In more particular:



                                                 +-----+
                                                 | GFA |
                                                 +-----+
                                                  ^  |
                                 2b. Regional Reg |  | 3b. Regional
Reply
                                                  |  |
                                                  |  v
                      +-----+ 1. Binding Update  +-----+
                      |     | -----------------> |     |
                      | oFA | 2. Binding Ack     | nFA |
                      |     | <----------------- |     |
                      +-----+                    +-----+


                      +-----+    Movement        +-----+
                      | MN  | - - - - - - - - -> | MN  |
                      +-----+                    +-----+
       Figure 4 - "source trigger" hand-off optionally using either AFA
or GFA

- 1 & 2 are mandatory messages that set a temporary (optionally
bi-directional) tunnel between oFA and nFA
- 2b & 3b are optional messages used if the BU includes a GFA or AFA
address

                                                 +-----+
                                                 | GFA |
                                                 +-----+
                                                  ^  |
                                 3b. Regional Reg |  | 4b. Regional
Reply
                                                  |  |
                              1. Binding Request  |  v
                      +-----+ <----------------  +-----+
                      |     | 2. Binding Update  |     |
                      | oFA | -----------------> | nFA |
                      |     | 3.  Binding Ack    |     |
                      +-----+ <----------------- +-----+


                      +-----+    Movement        +-----+
                      | MN  | - - - - - - - - -> | MN  |
                      +-----+                    +-----+
       Figure 5 - "target trigger" hand-off using either AFA or GFA

- 3b & 4b are optional messages used if the BU includes a GFA or AFA
address
- 1 & 2 & 3 are mandatory messages that set a temporary tunnel between
oFA
and nFA

The above modified version of the FA assisted has the following
advantages:
1. Fast Handoff is isolated from Regional Registration or other
hierarchical signaling.
2. The proactive establishment of the temporary tunnel between oFA and
nFA
provides Fast Handoff and helps to ensure zero packet loss during
handoff
3. Retains the main advantages of the original FA assisted proposal:
   - support for vanilla RFC2002 MIP clients,
   - no additional signaling over the radio link.
   - optional support for Regional Registration (or other hierarchical
solutions)

-Scott C. (and George T.)


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov 15 12:24:01 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23529
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 15 Nov 2000 12:24:00 -0500 (EST)
Received: from standards (47.234.32.16:4328) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5C55@standards.nortelnetworks.com>; Wed, 15 Nov 2000 12:04:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 107400 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Nov 2000 12:04:37
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBB5C53@standards.nortelnetworks.com>;
          Wed, 15 Nov 2000 12:04:36 -0500
Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id KAA07901; Wed, 15 Nov 2000 10:21:02
          -0700 (MST)
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,v1.7) with ESMTP id
          JAA14275; Wed, 15 Nov 2000 09:21:01 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id JAA23288; Wed, 15 Nov 2000 09:20:58
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Patrice Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.974308694.4769.pcalhoun@nasnfs>
Date:         Wed, 15 Nov 2000 09:18:14 -0800
Reply-To: Patrice Calhoun <Pat.Calhoun@eng.sun.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Patrice Calhoun <Pat.Calhoun@eng.sun.com>
Subject:      Re: [MOBILE-IP] v4 fast handoff lack of interest?
X-To:         George Tsirtsis <G.Tsirtsis@flarion.com>
X-cc:         "mscorson@ix.netcom.com" <mscorson@ix.netcom.com>,
              "Philip_Roberts-qa3445@email.mot.com"
              <Philip_Roberts-qa3445@email.mot.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <D0BFB433B390D411A6B500B0D07C53A10205DA@freeairmail.com>

I do appologize for the delay (and I must admit that this fell off my plate :(.
 below are my comments.

PatC
>
> -----Original Message-----
> From: M. Scott Corson
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Sent: 11/8/00 11:47 AM
> Subject: Re: [MOBILE-IP] v4 fast handoff lack of interest?
>
> ..
> Phil,
>
> Just on time we have some comments.....and you thought that no one cared
> :-)
>
> We feel that the FA assisted approach has a number of advantages over
> the
> fast handoff approach. Most of the arguments, however, have been made
> already in this list (see McCann's "[MOBILE-IP] Differences between the
> two
> MIPv4 handoff approaches" for an example). The most important arguments
> against Fast Handoff from our point of view is:
> 1. Increased signaling on the old link; which might be degrading.
> 2. Ability of the FA assisted approach to support vanilla RFC2002 MIP
> clients.
>
> We do, however, feel that the FA assisted proposal can be improved.
>
> Please consider the following modifications:
> Lets use the basic idea of Source and Destination Trigger but also
> support
> the following:
> 1. A temporary tunnel between old FA and new FA (whether GFA/AFA is used
> or
> not)
> 2. The creation of this temporary tunnel to be based on BR/BU/BUAck
> messages (see below)
> 3. Regional/Hierarchical mobile IP signaling to be optionally used in
> parallel to the 1,2
>
> In more particular:
>
>
>
>                                                  +-----+
>                                                  | GFA |
>                                                  +-----+
>                                                   ^  |
>                                  2b. Regional Reg |  | 3b. Regional
> Reply
>                                                   |  |
>                                                   |  v
>                       +-----+ 1. Binding Update  +-----+
>                       |     | -----------------> |     |
>                       | oFA | 2. Binding Ack     | nFA |
>                       |     | <----------------- |     |
>                       +-----+                    +-----+
>
>
>                       +-----+    Movement        +-----+
>                       | MN  | - - - - - - - - -> | MN  |
>                       +-----+                    +-----+
>        Figure 4 - "source trigger" hand-off optionally using either AFA
> or GFA
>
> - 1 & 2 are mandatory messages that set a temporary (optionally
> bi-directional) tunnel between oFA and nFA
> - 2b & 3b are optional messages used if the BU includes a GFA or AFA
> address
>
>                                                  +-----+
>                                                  | GFA |
>                                                  +-----+
>                                                   ^  |
>                                  3b. Regional Reg |  | 4b. Regional
> Reply
>                                                   |  |
>                               1. Binding Request  |  v
>                       +-----+ <----------------  +-----+
>                       |     | 2. Binding Update  |     |
>                       | oFA | -----------------> | nFA |
>                       |     | 3.  Binding Ack    |     |
>                       +-----+ <----------------- +-----+
>
>
>                       +-----+    Movement        +-----+
>                       | MN  | - - - - - - - - -> | MN  |
>                       +-----+                    +-----+
>        Figure 5 - "target trigger" hand-off using either AFA or GFA
>
> - 3b & 4b are optional messages used if the BU includes a GFA or AFA
> address
> - 1 & 2 & 3 are mandatory messages that set a temporary tunnel between
> oFA
> and nFA
>
> The above modified version of the FA assisted has the following
> advantages:
> 1. Fast Handoff is isolated from Regional Registration or other
> hierarchical signaling.

I believe that I can buy this argument... I have some small issues with
overloading a message type, but I cannot seem to justify them in the fact of
protocol simplicity.

> 2. The proactive establishment of the temporary tunnel between oFA and
> nFA
> provides Fast Handoff and helps to ensure zero packet loss during
> handoff

I agree.

> 3. Retains the main advantages of the original FA assisted proposal:
>    - support for vanilla RFC2002 MIP clients,
>    - no additional signaling over the radio link.
>    - optional support for Regional Registration (or other hierarchical
> solutions)

Correct.

Overall, I believe that I am in agreement with the proposed. I will discuss
this with the co-authors to ensure that they are also in agreement, and will
then submit a revised version before the deadline.

Thanks for the valuable input.

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov 15 17:17:37 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21118
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 15 Nov 2000 17:17:36 -0500 (EST)
Received: from standards (47.234.32.16:3382) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5D75@standards.nortelnetworks.com>; Wed, 15 Nov 2000 16:58:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 107799 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Nov 2000 16:58:37
          -0500
Received: from zmamail04.zma.compaq.com (mailout.zma.compaq.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB5D73@standards.nortelnetworks.com>; Wed, 15 Nov 2000
          16:58:36 -0500
Received: by zmamail04.zma.compaq.com (Postfix,
          from userid 12345) id 2AAFC7BD; Wed, 15 Nov 2000 17:15:12 -0500 (EST)
Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net
          [16.103.129.42]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id
          017A86DB; Wed, 15 Nov 2000 17:15:07 -0500 (EST)
Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service
          (5.5.2652.78) id <W5QBQQMV>; Wed, 15 Nov 2000 17:15:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain
Approved-By:  "Powell, Ken" <Ken.Powell@COMPAQ.COM>
Message-ID:  <C99A689B0CB9D111AF3F0000F8062CCD08FB83D8@zkoexc2.zko.dec.com>
Date:         Wed, 15 Nov 2000 17:15:06 -0500
Reply-To: "Powell, Ken" <Ken.Powell@compaq.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Powell, Ken" <Ken.Powell@compaq.com>
Subject:      Re: [MOBILE-IP] DAD
X-To:         Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> -----Original Message-----
> From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr]
> Sent: Wednesday, November 15, 2000 2:58 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] DAD
>
>
>  In your previous mail you wrote:
>
>    A node normally runs DAD only when creating a new address when
>    attached directly to its home subnet. The specific case that
>    was of concern occurs when a binding is dropped for a valid
>    address on the home network that already passed DAD. When the
>    binding gets re-created, the mobile node does not create a new
>    address, it reuses the old one.
>
> => for me to re-creat a binding or to re-assign an address to
> an interface
> is the same thing. The re- is covered by the manual configuration case
> (which is a common way to re-use the same address in the RFC
> 2462 context).
> But the question is: this is obvious or this needs clarification?

I vote for clarification. Its a subtle point that seemed obvious
to me too, but only after the initial question was asked. I didn't
even consider the possibility before that.

>
>    I think the definition of what it means to assign an address to
>    an interface is a bit fuzzy with mobility.
>
> => perhaps this is the point which needs clarification. I believe
> for a mobile node to assign an address to an interface attached to
> the home link or to perform a new home registration (ie. to create
> a new binding with a home agent, new is relative to the home address
> not the care-of) are the same thing.

OK, how about:

       .... The mobile node SHOULD set the Duplicate Address
       Detection (D) bit based on any requirements for Duplicate
       Address Detection that would apply to the mobile node if it
       were at home [17, 27]. It is possible for the mobile node
       to retain a home address for a period of time without a
       current home registration. Creation of a new home
       registration for such an address MUST be treated the same
       as assigning a new address to the home subnet interface.

>
> Regards
>
> Francis.Dupont@enst-bretagne.fr
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 16 04:26:42 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22640
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 16 Nov 2000 04:26:41 -0500 (EST)
Received: from standards (47.234.32.16:3535) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5F88@standards.nortelnetworks.com>; Thu, 16 Nov 2000 4:08:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 108492 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Nov 2000 04:08:04
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB5F86@standards.nortelnetworks.com>; Thu, 16 Nov 2000 4:08:04
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAG9Ocb45592; Thu, 16 Nov 2000 10:24:38 +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 KAA21611; Thu, 16 Nov 2000 10:24:38 +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.9.3/8.9.3) with
          ESMTP id KAA89805; Thu, 16 Nov 2000 10:26:52 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011160926.KAA89805@givry.rennes.enst-bretagne.fr>
Date:         Thu, 16 Nov 2000 10:26:51 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] Placement for Binding Update and Home Address
              options
X-To:         Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Wed, 15 Nov 2000 15:55:19 CST. 
              <0DF9920C9AD8D211AB0C0008C7CF1C9A0498FC93@il27exm02.cig.mot.com>

 In your previous mail you wrote:

   => I agree, home address and tunnel encapsulation limit between routing
   and fragment, all other destination options (binding XXX) after ESP.

      Comments?

   Does this mean that we are leaving the home address information
   without confidentiality protection?

=> you can't easily make the home address confidential because the ESP
processing needs to know the real source (ie. the home address) in
the SA selector phase :
 - or you hack your IPsec implementation in order to get the home address
   and to use it
 - or you hack your IPsec implementation in order to skip the SA selector
   phase but you can introduce a security problem
 - or you build the SA with the care-of address and you have to rebuild
   it at each movement
(then it is not easy as I've said :-).
BTW why do you want to hide the home address information?

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 16 04:38:11 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27553
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 16 Nov 2000 04:38:10 -0500 (EST)
Received: from standards (47.234.32.16:3535) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5FE6@standards.nortelnetworks.com>; Thu, 16 Nov 2000 4:19:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 108625 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Nov 2000 04:19:33
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB5FE4@standards.nortelnetworks.com>; Thu, 16 Nov 2000 4:19:32
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAG9a6b46437; Thu, 16 Nov 2000 10:36: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 KAA21898; Thu, 16 Nov 2000 10:36:05 +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.9.3/8.9.3) with
          ESMTP id KAA89892; Thu, 16 Nov 2000 10:38:19 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011160938.KAA89892@givry.rennes.enst-bretagne.fr>
Date:         Thu, 16 Nov 2000 10:38:19 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] DAD
X-To:         "Powell, Ken" <Ken.Powell@compaq.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Wed, 15 Nov 2000 17:15:06 EST. 
              <C99A689B0CB9D111AF3F0000F8062CCD08FB83D8@zkoexc2.zko.dec.com>

 In your previous mail you wrote:

   OK, how about:

          .... The mobile node SHOULD set the Duplicate Address
          Detection (D) bit based on any requirements for Duplicate
          Address Detection that would apply to the mobile node if it
          were at home [17, 27]. It is possible for the mobile node
          to retain a home address for a period of time without a
          current home registration. Creation of a new home
          registration for such an address MUST be treated the same
          as assigning a new address to the home subnet interface.

=> I agree, just use the world "link" in place of "subnet",
ie last line should be:
          as assigning a new address to a home link interface.

Thanks

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 16 09:02:03 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06220
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 16 Nov 2000 09:02:02 -0500 (EST)
Received: from standards (47.234.32.16:1236) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6123@standards.nortelnetworks.com>; Thu, 16 Nov 2000 8:43:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 109058 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Nov 2000 08:43:33
          -0500
Received: from mailbreak.com (216.207.225.170:2837) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB6121@standards.nortelnetworks.com>; Thu, 16 Nov 2000
          8:43:33 -0500
Received: from SOLID [166.84.159.26] by mailbreak.com [216.207.225.174] with
          SMTP (MDaemon.v3.5.0.R) for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Thu, 16 Nov 2000 08:52:52 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0356_01C04FAC.1FCE31F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-MDRemoteIP: 166.84.159.26
X-Return-Path: eunsoo@mailbreak.com
X-MDaemon-Deliver-To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Approved-By:  Eunsoo Shim <eunsoo@MAILBREAK.COM>
Message-ID:  <035901c04fd6$09078fa0$6401a8c0@SOLID>
Date:         Thu, 16 Nov 2000 09:03:45 -0500
Reply-To: Eunsoo Shim <eunsoo@mailbreak.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Eunsoo Shim <eunsoo@mailbreak.com>
Subject:      [MOBILE-IP] from FA to MN
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

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

Hi,

May I ask a question?
When the MN uses a care-of-address which is an address of the FA, the FA =
should be able to send IP packets to the MN using the MN's Home IP =
address.
Is it assumed that there is no intermediate router betwee the FA and the =
MN? That is, is the MN reachable using only link layer address?
Thank you.

Eunsoo

------=_NextPart_000_0356_01C04FAC.1FCE31F0
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.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#c0c0c0>
<DIV><FONT size=3D2>Hi,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>May I ask a question?</FONT></DIV>
<DIV><FONT size=3D2>When the MN uses a care-of-address which is an =
address of the=20
FA, the FA should be able to send IP packets to the MN using the MN's =
Home IP=20
address.</FONT></DIV>
<DIV><FONT size=3D2>Is it assumed that there is no intermediate router =
betwee the=20
FA and the MN? That is, is the MN reachable using only link layer=20
address?</FONT></DIV>
<DIV><FONT size=3D2>Thank you.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Eunsoo</FONT></DIV></BODY></HTML>

------=_NextPart_000_0356_01C04FAC.1FCE31F0--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 16 10:37:22 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14425
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 16 Nov 2000 10:37:22 -0500 (EST)
Received: from standards (47.234.32.16:3812) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB619F@standards.nortelnetworks.com>; Thu, 16 Nov 2000 10:18:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 109223 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Nov 2000 10:18:35
          -0500
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBB619D@standards.nortelnetworks.com>; Thu, 16 Nov 2000 10:18:34
          -0500
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP
          id eAGFZBZ08220 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 16
          Nov 2000 16:35:12 +0100 (MET)
Received: from era.ericsson.se by era-t.ericsson.se
          (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA28802; Thu, 16 Nov 2000 16:35:11
          +0100
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
References: <200011160938.KAA89892@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Mattias Pettersson <mattias.pettersson@ERA.ERICSSON.SE>
Message-ID:  <3A13FEA5.1914489A@era.ericsson.se>
Date:         Thu, 16 Nov 2000 16:35:01 +0100
Reply-To: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Radio Systems AB
Subject:      Re: [MOBILE-IP] DAD
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I think clarification is inexpensive, so please go for it.

/Mattias


Francis Dupont wrote:
>
>  In your previous mail you wrote:
>
>    OK, how about:
>
>           .... The mobile node SHOULD set the Duplicate Address
>           Detection (D) bit based on any requirements for Duplicate
>           Address Detection that would apply to the mobile node if it
>           were at home [17, 27]. It is possible for the mobile node
>           to retain a home address for a period of time without a
>           current home registration. Creation of a new home
>           registration for such an address MUST be treated the same
>           as assigning a new address to the home subnet interface.
>
> => I agree, just use the world "link" in place of "subnet",
> ie last line should be:
>           as assigning a new address to a home link interface.
>
> Thanks
>
> Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 16 10:56:36 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21085
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 16 Nov 2000 10:56:36 -0500 (EST)
Received: from standards (47.234.32.16:3812) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB61E5@standards.nortelnetworks.com>; Thu, 16 Nov 2000 10:38:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 109321 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Nov 2000 10:38:04
          -0500
Received: from mail.lysator.liu.se by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB61E3@standards.nortelnetworks.com>; Thu, 16 Nov 2000 10:38:03
          -0500
Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by
          mail.lysator.liu.se (Postfix) with ESMTP id A8EE824027E7 for
          <mobile-ip@standards.nortelnetworks.com>; Thu, 16 Nov 2000 16:54:40
          +0100 (MET)
Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id
          QAA03240; Thu, 16 Nov 2000 16:54:40 +0100 (MET)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Lines: 183
X-Mailer: Gnus v5.7/Emacs 20.7
Approved-By:  nisse@LYSATOR.LIU.SE
Message-ID:  <nn1ywb9akf.fsf@sture.lysator.liu.se>
Date:         Thu, 16 Nov 2000 16:54:40 +0100
Reply-To: nisse@lysator.liu.se
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Niels Möller <nisse@lysator.liu.se>
Subject:      [MOBILE-IP] Simpler AAA for public networks with no accounting
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

Hello all,

I'm not intimately familiar with mobile ip, but I have at least read
RFC 2002, RFC 2977 and draft-ietf-mobileip-ipv6-12.txt. I'm thinking
about a special case, namely mobile wireless networks that are (i)
public, and (ii) not accounted.

By (i), I mean that the operator is willing to provide access to
anyone who shows up in the area, and by (ii) I mean that the operator
either doesn't charge the users anything for access, or that he
accepts payments using some (possibly anonymous) digital payment
system that is orthogonal to the network infrastructure. The operator
still need some way to track users that abuse the system.

Free access with no charge may seem unrealistic, but it may not be. If
I already pay for a decent 10Mbps or more connection to my home or to
my office, and if I can get a base station for $1000 or less, I or the
company may be willing to install a base station, and let friends,
employees and passers-by use it freely (perhaps bandwidth limited or
routed with a lower priority). Likewise, for cafés, hotels, airports
etc that already happen to have a decent net connection, the cost for
setting up a few base stations may get low enough that there's no
point in charging extra for it; if customers like it and stay for
another beer or coffee, that's good enough.

So, what simplifications can be applied to this case? To me, it seems
that one can do away with all the security associations except the
ones between mobile nodes and their respective home agents, and still
get an appropriate level of security.

It's true that one really needs an association between the mobile node
an the base station/FA/access point in order to get good protection
against link level attacks, like eavesdropping and connection
high-jacking. However, for highly sensitive data, one ought to use
end-to-end security anyway, and we may be able to live with the other
threats.

One effort to get public networks off the ground, with a minimum of
central organization, can be found at <URL:
http://www.elektrosmog.nu>. One draft for its security architecture
can be found at <URL:
http://www.lysator.liu.se/~nisse/misc/elektrosmog-authentication.txt>,
included below for convenience. I appreciate your comments, in
particular for the final section on using Mobile IP.

Best regards,
/Niels Möller

--------------8<-----------------
On the first elektrosmog meeting (2000-09-03) we talked about
authentication of elektrosmog users. What follows below are some of my
thoughts on the issue.

Connecting to the Internet via Elektrosmog is a process that takes
several steps.

1. The client talks to a local DHCP server (or stateless address
   autoconfiguration for IPv6). This is done with no authentication
   whatsoever; anyone can get an ip-address on the local network. A
   side effect is any client can communicate with other nearby
   clients, without needing to associate with elektrosmog.

2. Next, the client talks to the base station to authenticate. One
   probably needs to support several authentication mechanisms; for
   local users one may use kerberos or SRP paswords (clear text
   passwords are obviously not suitable). In order to authenticate
   users that are not previously known by the base station one needs
   something more scalable, e.g. dh + spki certificates. One may want
   to look at the IETF AAA working group.

   The output from a successful authentication should create the
   following values:

   A. A session key shared between the base station and the client,
      used for creating a pair of IPSEC tunnels between the client and
      the base station. Packets received from the client that are
      properly authenticated using the session key are routed to the
      Internet, and packets from the Internet to the client are routed
      back using the tunnel.

   B. Some kind of identity that can be used to track misbehaving
      users. It doesn't have to be a globally unique name; it's good
      enough with some pseudonym and some kind certificate from
      someone who promises to reveal the real identity in case of
      abuse. One could also use Freedom-like pseudonyms that can never
      be tracked, but costs some amount of money to get and are
      blacklisted in case of abuse.

   C. Information on whether or not the user should be charged for the
      connection, and if so, how much, and by which micro payment
      mechanism and from which account. The user should also get
      information about how much this base station wants to charge.


   (B) and (C) are independent: B is needed to deal with abuse (if we
   beliee we have to do that; why would a spammer or cracker use a
   slow wireless network in a public area?), while C is for accounting
   and charging.

3. The lifetime of the tunnel created in (A) is called a "session".
   Sessions can cost money. The easiest way to make sure that a user
   pays for the right amount of connection time (i.e. if we forget
   about all the other problems with electronic payments) is perhaps
   to use some kind of "tickets". The base station tells the client
   what the price is for a ticket and how long a ticket is valid (this
   lifetime is called a "period").

   For each ticket period, the client sends a valid payment including
   a sequence number to the base station. If the base station doesn't
   recieve payment in time, it sends a reminder, telling the client
   which sequence number it expects (analogous to a pay phone buzzing
   when you need to insert another coin). If payment is not received
   in reasonable time, and a few reminders have been sent, the base
   station stops routing packets through the tunnel. The tunnel state
   can be kept around for some more time, so that the client can
   reactivate it by just sending another payment.

   It is important that retransmissions of payments really are exact
   copies, so that the base stations can't charge the user for each of
   the retransmitted copies of a ticket. The payment can simply be a
   certificate authorizing the base station operator to withdraw a
   certain amount of money from a given account, but more efficient
   mechanisms are possible.

   The payment protocol can be run on a tcp connection, which is kept
   open for the life time of a session (if one believes that tcp's
   handling of retransmissions etc is appropriate for this
   application), or some special udp-based protocol [ paf commented
   that we *should* use tcp ]. Details depends on the payment protocol
   being used.


A few other things that need consideration...

Is it possible to use DHCP to tell the clients where to find an
authentication server and a payment server? Or should one use a server
location protocol? Or used fixed "private" addresses like 10.0.0.17
for Elektrosmog-local servers?

For some authentication mechanisms, a client may need to speak to the
outside world in order to authenticate to the base station. For
example to run kinit one will need to talk to a kerberos server, and
probably also with some dns server. So the base station should be able
to route some unauthenticated traffic.


Mobile IP issues

At the latest meeting (2000-10-10) we talked about using mobile ip
(RFC 2002) to solve authentication as required in (B). The idea is
that the mobile node (i.e. the Elektrosmog client) has a Security
Association (i.e. a shared secret key) with some Home Agent. The base
station (or some other local server) acts as a Foreign Agent. There
are no security associations between the FA and either of the MN or
HA.

Now, the the MN sends a Registration Request to the FA which forwards
it to the HA. The home agent replies with a Registration Reply, send
to the FA and forwarded to the MN. We have to use a "Co-Located
Care-of address", as there's no SA between the HA and FA.

The crucial question is: Does this qualify as a identification as in
(B), from the point of view of FA, the base station? An abuser could
set up some kind of "fake" home agent, and use that to get access or
give access to other abusers.

I think it is sufficient, assuming that we don't try to do accounting.
An abuser that is able to set up a machine to answer registration
requests for him, could just as well have used the machine directly
for mounting his cracking or spamming attempts; it probably have
better bandwidth than the elektrosmog system. And in any case, the
elektrosmog station will log each user's ip-address with its home
adress and the address of the home agent, so an extra hop via
elektrosmog will not provide much hiding.

We want assure tha FA that abuse by MN can be blamed on the owner of
HA. But FA doesn't trust MN, and it doesn't trust HA. Would it be
possible for a MN to send some messages to an unrelated innocent HA,
fool the FA to think that the registration with HA was successful, and
start routing? If so, abuse by MN will be blamed on FA or HA, which
are both innocent.

/Niels


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 16 13:08:06 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10703
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 16 Nov 2000 13:07:53 -0500 (EST)
Received: from standards (47.234.32.16:3798) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB628E@standards.nortelnetworks.com>; Thu, 16 Nov 2000 12:46:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 109547 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Nov 2000 12:46:44
          -0500
Received: from mail.icu.ac.kr (210.107.128.31:36654) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB628C@standards.nortelnetworks.com>; Thu, 16 Nov 2000
          12:46:32 -0500
Received: from jkchoi (v33-170.icu.ac.kr [210.107.133.170]) by mail.icu.ac.kr
          (8.9.2/8.9.3) with SMTP id DAA00855; Fri, 17 Nov 2000 03:01:38 +0900
          (KST)
MIME-Version: 1.0
Content-Type: multipart/mixed;
              boundary="----=_NextPart_000_0020_01C05043.383EE210"
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
Approved-By:  Jun Kyun Choi <jkchoi@ICU.AC.KR>
Message-ID:  <002201c04ff7$ca494610$aa856bd2@jkchoi>
Date:         Fri, 17 Nov 2000 03:05:20 +0900
Reply-To: Jun Kyun Choi <jkchoi@icu.ac.kr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Jun Kyun Choi <jkchoi@icu.ac.kr>
Subject:      [MOBILE-IP] Submission of draft text at Mobile IP WG
X-To:         qa3445@email.mot.com, basavaraj.patil@nokia.com
X-cc:         internet-drafts@ietf.org, =?ks_c_5601-1987?B?vue8scjx?= 
              <shyang@etri.re.kr>,
              =?ks_c_5601-1987?B?wMzAr7Dm?= <leeyk@etri.re.kr>,
              =?ks_c_5601-1987?B?sejAur7G?= <eakim@etri.re.kr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0020_01C05043.383EE210
Content-Type: text/plain;
        charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

RGVhciBDaGFpcm1hbiBvZiBtb2JpbGVpcCBXRywNCg0KSSB3b3VsZCBsaWtlIHRvIHN1Ym1pdCB0
aGUgZHJhZnQgdGV4dCBhdCB0aGUgU2FuIERpZWdvIG1lZXRpbmcuDQpUaGUgdGl0bGUgaXMgZXh0
ZW5zaW9uIG9mIExEUCBmb3IgbW9iaWxlIElQIHNlcnZpY2UgdGhyb3VnaCB0aGUgTVBMUyBuZXR3
b3JrIGFzIDxkcmFmdC1jaG9pLW1vYmlsZWlwLWxkcGV4dC0wMC50eHQ+LiBNeSBwcm9wb3NhbCBp
cyB0aGF0IHRoZSBMRFAgcHJvdG9jb2wgb2YgdGhlIE1QTFMgbmV0d29yayBjYW4gZXh0ZW5kIHRv
IG1vYmlsZSBJUC4gVGhpcyBkb2N1bWVudCBpcyBvbmUgb2YgcmVzZWFyY2ggcmVzdWx0cyB0aGF0
IHRoZSBNUExTIHN3aXRjaGluZyBzeXN0ZW0gZGV2ZWxvcGVkIGJ5IEVUUkkgdHJpZXMgdG8gaW50
ZWdyYXRlIHRoZSBtb2JpbGUgSVAgc2VydmljZS4NCg0KUGxlYXNlLCByZXZpZXcgbXkgZG9jdW1l
bnQgYW5kIGdpdmUgbWUgYSBjb21tZW50Lg0KDQpJdCBpcyBhIGZpcnN0IHRpbWUgZm9yIG1lIHRv
IHN1Ym1pdCB0aGUgZHJhZnQgYXQgSUVURiBtZWV0aW5nLCBUaGVuLCBJIGRvbid0IGhhdmUgYW55
IGtub3dsZWRnZSBvZiBJRVRGIHByb2Nlc3MuIA0KUGxlYXNlLCBhZHZpc2UgbWUgaG93IHRvIG1h
a2UgYSBwcm9ncmVzcy4NCg0KQ291bGQgeW91IGFsbG93IG1lIDUgbWluLiBmb3IgdGhlIHByZXNl
bnRhdGlvbiBvZiBteSBkb2N1bWVudCBhZnRlciBwcmVzZW50YXRpb24gb2YgZHJhZnQtemhvbmct
bW9iaWxlLWlwLW1wbHMtMDEudHh0ID8gKEkgZm91bmQgdGhlIHByb3Bvc2VkIGFnZW5kYSBmb3Ig
dGhlIFNhbiBEaWVnbyBtZWV0aW5nIGF0IHRoZSB3ZWIuKQ0KSWYgSSBnZXQgYSB0aW1lIHRvIHBy
ZXNlbnQsIGl0IG1heSBiZSBhIGdvb2QgdGltZSBmb3IgZGlzY3Vzc2lvbiB3aXRoIFpob25nJ3Mg
ZG9jdW1lbnQuDQpTaW5jZXJlbHkgeW91cnMsDQoNCkp1biBLeXVuIENob2kNCkFzc29jaWF0ZSBQ
cm9mZXNzb3INCkluZm9ybWF0aW9uIGFuZCBDb21tdW5jYXRpb25zIFVuaXZlcnNpdHkNCjU4LTQg
SHdhIEFobSBEb25nLCBZdXNvbmcsDQpUYWVqb24sIEtvcmVhDQoNCg0KDQoNCg0K

------=_NextPart_000_0020_01C05043.383EE210
Content-Type: text/plain;
        name="draft-choi-mobileip-ldpext-00.txt"
Content-Disposition: attachment;
        filename="draft-choi-mobileip-ldpext-00.txt"
Content-Transfer-Encoding: quoted-printable



 MPLS Working Group                                      Jun Kyun Choi
 Internet Draft                                                    ICU
 Document: draft-choi-mobileip-ldpext-00.txt            Yoo Kyoung Lee
                                                                  ETRI
                                                          Sun Hee Yang
                                                                  ETRI
                                                            Eun Ah Kim
                                                                  ETRI
                                                          December 2000


                   Extension of LDP for Mobile IP Service
                          through the MPLS Network
                    <draft-choi-mobileip-ldpext-00.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 except that the right to
   produce derivative works is not granted.

   This document is an Internet-Draft and is NOT offered in accordance
   with Section 10 of RFC2026, and the author does not provide the IETF
   with any rights other than to publish as 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

   This document discusses how to build the large-scale mobile IP
   network through the MPLS network. One small-scale mobile IP network
   could be connected to other networks through the MPLS backbone
   network.
        It proposes the MPLS network architecture to provide the large-
   scale mobile IP network. Specifically, it proposes that the label
   distribution protocol (LDP) can be applied to set up the Label
   switched path (LSP) tunnels between the mobile agents (that is,
   Foreign Agents and Home Agents)[3]. It means that the IP-in-IP
   tunnels can be replaced by one or multiple Label switched paths
   (LSPs) on the MPLS network.



Choi et al.                  Expires July 2001                  [Page 1] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000



Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [2].


Table of Contents

   1. Introduction
   2. The MPLS Network Architecture with Mobility Support
      2.1. Assumptions and Requirements
      2.2. Network Architecture and Service Scenarios
      2.3. Routing considerations
      2.4. Interworking of existing Mobile IP network
   3. Description of the Protocol
      3.1. General Assumptions
      3.2. LSP Tunnels for Mobility Support
      3.3. Registration of Mobile Node
      3.4. Agent Advertisement and Solicitation
      3.5. Location Query of Mobile Node
      3.6. LSP Extension for Handover
      3.7. LSP Recalculation
   4. Required Messages and TLVs
      4.1. Required Messages and TLVs
      4.2. Registration Message
      4.3. Agent Advertisement and Solicitation Messages
      4.4. Location Query and Response Messages
      4.5. LSP Extension Message
      4.6. LSP Recalculation Message
   5. IANA Considerations
   6. Security Considerations
   7. References
   8. Author's Addresses
   9. Full Copyright Statement


















Choi, et al.               Expires July 2001                   [Page 2] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


1. Introduction

   A mobile node of a Mobile IP network may be connected to Foreign
   Mobile IP networks with a distance. The MPLS network can provide the
   backbone solution for high speed IP forwarding. The relevant label
   switched paths on the MPLS network can support proper quality-of-
   service (QoS) paths for differentiated mobile IP services. This
   document proposes the MPLS network architecture and tunneling
   procedures to support the mobile IP network. Similar concerns on the
   integration of MPLS network and Mobile IP network are also
   investigated in [8].

   The MPLS backbone network can build the large-scale mobile IP =
network.
   A mobile IP network is connected to other mobile IP network via the
   Label Edge Router (LER). To support Mobile IP services, The MPLS
   network have to accommodate Foreign Agent and Home Agent. The LER is
   capable of forwarding Mobile IP packets by encapsulating with
   relevant label header. The LER (Label Edge Router) would be a Foreign
   Agent or its corresponding node. For mobility support, the LER will
   be a gateway router for the corresponding mobile IP network. To
   support the hierarchical architecture, the Gateway FA or Regional FA
   could be defined on the MPLS network [4].

   For the control procedure, the label distribution protocol (LDP) may
   be extended to set up the Label switched path (LSP) tunnel between
   the mobile agents (that is, Foreign Agents and Home Agents) through
   the MPLS network [3]. The IP-in-IP tunnels of Mobile IP Network can
   be provided by the one or multiple LSPs through the MPLS network.
   When a mobile node is moving to the foreign area, the existing LSPs
   may be extended without service interrupt. The short-cut LSPs between
   source and destination mobile nodes may be recalculated to avoid the
   long cascaded connections.

   The Home Agent can be implemented on the relevant MPLS routers
   according to geographical area and routing path. There may be two
   types of scenarios according to location of Home Agent (HA). Scenario
   1 (we call it, Tunnel Extension) is a natural extension of the
   existing mobile IP protocol through the MPLS network. The MPLS
   network provides the LSP tunnels replaced by the IP-in-IP tunnels.
   Scenario 2 (we call it, Query Before Tunneling) is that the HA is
   attached at the LSR like a server since it couldn=92t intercept the
   incoming IP packets to forward the destination FA belonging to the
   visiting area of a mobile node.

   Scenario 1 (Tunnel Extension) is based on the existing scenario of
   Mobile IP service and the HA should be located at the LER [5],[6]. In
   this scenario, the IP-in-IP tunnels between HA and FA could be done
   with help of the LDP operation. There is no additional constraints on
   the existing protocols of mobile IP.

   Scenario 2 (Query Before Tunneling) is that the HA is attached or
   located at the Label Switching Router (LSR). It assumes that the LSR
   is not directly connected to the regional mobile IP network and the

Choi, et al.               Expires July 2001                   [Page 3] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


   HA doesn=92t be capable to intercept the mobile IP packets for
   tunneling. In this case, the similar scenario with the existing
   cellular or IMT-2000 network using home location register/visit
   location register (HLR/VLR) can be applied. The ingress LER may query
   the care-of-address (CoA) of the egress LER/FA from the HA to find
   the direct short-cut path. The forwarding path should be pre-
   calculated by query process. The cache imposition or label binding
   operation may be done at the LER/FA.

   To deliver the mobile IP packets through the MPLS network, it
   requires the IP encapsulation [7]. Far from home location, the mobile
   node should be registered to the foreign LER with proper agent
   discovery process. The registration process should be also needed
   between the HA and the corresponding FA through the MPLS network.
   While a node tries to call the mobile node, data forwarding path with
   help of HA should be established between the source LER and the
   destination LERs. The label switched path (LSP) by the LDP operation
   would enable to label the IP packets and forwards them at the
   destination mobile node via the MPLS network.


2. The MPLS Network Architecture with Mobility Support

2.1. Assumptions and Requirements

   In order to provide the backbone solution for Mobile IP network, it
   considers the following assumptions on the MPLS network.

     - There is no additional requirements on the existing mobile IP
       protocol such as agent discovery, registration, and routing.
     - All the regional mobile IP networks should be connected at the
       LER which will be a external gateway router to communicate the
       external world.
     - In the MPLS backbone network, all the LERs are equipped with FA
       to identify the visiting mobile nodes. In case that a number of
       FAs are in a Mobile IP network, the FA attached to the LER has a
       responsibility to communicate to the external world.
     - The HA should be located at the LER or the LSR. If a small-scale
       mobile IP network already has a number of HAs to cover their own
       regional area, it should discriminate from the HAs interfaced to
       the MPLS network. The relevant registration procedure is required
       for the mobile IP network on a number of HA. A mobile node should
       register the HA interfaced to the MPLS network while moving to
       external world. It can extend the registration procedure of
       mobile IP service [5],[6].
     - The forwarding process on the MPLS network should be taken on the
       datagram IP traffic (the UDP traffic) as well as the stream-like
       IP traffic (the TCP traffic).

   Depending on the location of HA on the MPLS network, the following
   assumptions are required.



Choi, et al.               Expires July 2001                   [Page 4] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


  - In Scenario 1 (Tunnel Extension), all the LERs have to operate the
    HA. It means that a mobile node should be identified both from the
    HA and the FA at visiting area while moving to foreign area [5],[6].
  - When a node sends the IP packets to the mobile node, the LER with HA
    intercepts and forward them to the corresponding LER/FA on
    temporarily visiting area.

  - In Scenario 2 (Query Before Tunneling), the HA is not located at the
    home LER. It means that the HA couldn=92t intercept IP packets. For
    this scenario, we assume that the data forwarding paths should be
    pre-calculated at the originating LER. When a node sends IP packets
    to the destination mobile IP node, the ingress LER has to decide
    whether forwarding to home area or not. Otherwise, it have to query
    from the HA to get the IP address of the destination LER/FA at a
    temporarily visit area.


2.2. Network Architecture and Service Scenarios

   The MPLS network to support mobile IP service doesn=92t use IP in IP
   encapsulation. The label switched path (LSP) tunnel provides a lower
   layer tunneling scheme independent on high layer applications. It
   notes that the IP-in-IP tunneling utilizes the layer 3 forwarding
   capability in IP routing. The ingress LER forwards IP packets all the
   way to the HA to the egress LER to the foreign mobile node. The whole
   forwarding process is done at the MPLS layer. The HA doesn't need to
   involve the IP layer forwarding to a mobile node.

   Since label header is much smaller than IP encapsulation header, the
   header overhead from HA to FA is also reduced. It can improve the
   scalability of mobile IP protocol. Moreover, an LSP satisfying the
   quality-of-service (QoS) requirements and traffic engineering could
   be set up with Constraint-Based Label Distribution Protocol (CR-LDP)
   or RSVP-TE [9],[10].

   Figure 1 shows the MPLS network architecture using Scenario 1 (Tunnel
   Extension). In this scenario the HA is located at the LER1 and has a
   capability to intercept IP packets for a mobile node. When a mobile
   node from the LER1/HA area is temporarily moving to the LER2 area,
   the registration is required to HA via LER2/FA2. When a node at LER3
   sends IP packets to a current mobile node, the LSP tunnels would be
   established from LER3 to LER1 and cascading from LER1 to LER2. The
   relevant LDP operations will be taken with associations of Forwarding
   Equivalence Class (FEC). When a mobile node is moving to the LER4/FA2
   area during active service time, the LSP tunnel from LER1 to LER2
   should be extended or re-configured to LER4 with update on HA, FA1
   and FA2. The seamless LSP tunnel to LER4 may be required for the
   real-time applications.

   To encapsulate IP packets with a MPLS header, the destination address
   of the MPLS header is initially the LER2. The MPLS label stack
   operation may cut through the corresponding address of the tunnel's
   receive endpoint. If the ingress point of the LSP tunnel wishes to

Choi, et al.               Expires July 2001                   [Page 5] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


   put a labeled packet into the MPLS network, it should replace the
   label value at the top of the stack with a label value that was
   distributed to it by the tunnel's receive endpoint. Then it must push
   on the label which corresponds to the tunnel itself, as distributed
   to it by the next hop along the tunnel. To allow this, the tunnel
   endpoints should be explicit label distribution peers.

                                                   +----------+
                                                   | Foreign  |
              +------------------------------+     | Mobile IP|
              |      The MPLS Network      +-+--+  | Network  |
              |    with Mobility Support   | FA1|  | +------+ |
+---------+ +----+                        /|LER2|--+-|old MN| |
|Home     | | HA |  +------+  +------+   / +--+-+  | +------+ |
|Mobile IP+-+LER1|--| LSR1 +--+ LSR2 |--+     |    +----------+
|Network  | |----+  +------+  +------+   \    |
+---------+   |  \     |                  \   |    +----------+
              |   \    |                   \  |    | Foreign  |
              |    \   |                    \ |    | Mobile IP|
              |     \  |                   +-++-+  | Network  |
              |    +-+-+--+                | FA2|  | +------+ |
              +----| LER3 |----------------|LER4|--+-|New MN| |
                   +---+--+                +----+  | +------+ |
                       |                           +----------+
                     +-+--+
                     | FN |
                     +----+

     LER: Label Edge Router
     LSR: Label Switching Router
     HA: Home Agent
     FA: Foreign Agent
     MN: Mobile Node
     FN: Fixed Node

      Figure 1. The MPLS Network Architecture with Mobility Support
                     (Scenario 1 : Tunnel Extension)


   In this scenario, the functions of correspondent agents, FA, can be
   located in the LERs. The LSPs can be setup the same way as "tunnels"
   are setup between correspondent agents and foreign agents. Since an
   LSP can be setup between a correspondent agent and a foreign agent
   (the LERs), this allows for traffic aggregation between the LERs. In
   addition it allows constrained based routing and the QoS path between
   the agents can be guaranteed. The establishment of these LSPs can be
   triggered by the Binding Update messages, by data transmitted,
   configured a priori or by other means.

   In the registration procedure, the mobile node (MN) determines
   whether it is at home or in a foreign network when it receives agent
   advertisement messages broadcast by the mobility agents. If the MN
   determines that it is in a foreign network, the MN acquires a

Choi, et al.               Expires July 2001                   [Page 6] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


   temporary CoA from FA and sends a registration request to FA. Since
   FA is an edge LER, it will analyze the incoming registration request
   message and get the destination address of the request. Then, FA
   updates its routing table with the value of MN home address. In
   addition, it sets the outgoing port value of this entry to be the
   incoming port number from which it received the registration request.
   Based on the IP routing table, FA forwards the registration request
   message toward HA.

   The registration request message is forwarded to HA using normal IP
   hop-by-hop routing. When HA gets the registration request message and
   learns the CoA, it searches its label table to find the table with
   the MN home address as Forwarding Equivalence Class (FEC). Then, it
   will send a label request using CR-LDP to FA with the CoA as FEC. FA
   replies with an LDP label mapping message to HA. When this label
   mapping message arrives at HA, the LSP would have been established.

   After that, HA changes its label table that uses the MN home address
   as FEC. It sets the outgoing port entries of the LSP from HA to FA.
   In this way, HA can relay the packets destined to MN home address to
   its current location in the foreign network. Finally, HA sends a
   registration reply to FA along the LSP from HA to FA. When FA
   receives the registration reply, it records the incoming port number
   and in label value of the reply message.

   Packets from a node to the MN are addressed to the MN home address.
   If the MN is located in a foreign network, packets are intercepted by
   the HA. HA uses the incoming label value as an index to look up its
   label table. HA inserts the label value in the label table into
   packet and sends it out through the port indicated in the table. If
   MN is still in the home network, then outgoing port entries are =
empty.
   The packet will be sent to the IP layer and sent out from the port
   indicated in the corresponding routing table entry. The first packet
   is delivered from HA to FA along the LSP (LER1-LSR1-LSR2-LER2) by
   label swapping. FA receives the first packet and looks up its label
   table. Since it is the egress of the LSP from HA to FA and the
   outgoing port entries are empty, FA strips off the label and sends
   the packets to the IP layer. Finally, FA forwards the packet to MN
   based on the newly-added host specific routing table. MN receives the
   packet sent by a originating node. Directly after delivering the
   first packet, HA transmits the CoA of MN to the ingress LER. After
   the LER of FN receives the CoA of MN form HA, the new LSP (LER3-LSR1-
   LSR2-LER2) between the LER and FA is established. From the next
   packet, the LER is directly delivered to FA using the newly-
   established LSP tunnel which is reduced the distance of FN and MN.

   When MN moves from one FA to another, the registration procedure is
   repeated once between the HA and new FA. The existing LSP should be
   changed to the new FA. The following issues are further considered on
   the MPLS network.

       - Path rerouting
       - Path extension

Choi, et al.               Expires July 2001                   [Page 7] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


       - Label binding for the LSP from FN to new FA


              +------------------------------+
              |      The MPLS Network        |     +----------+
              |    with Mobility Support     |     | Foreign  |
              |      +----+                  |     | Mobile IP|
              |      | HA |                +-+--+  | Network  |
              |      +-+--+                | FA1|  | +------+ |
+---------+   |        |                  /|LER2+--+-|old MN| |
|Home     | |-+--+  +--+---+  +------+   / +--+-+  | +------+ |
|Mobile IP+-+LER1+--+ LSR1 +--+ LSR2 +--+     |    +----------+
|Network  | |----+  +--+---+  +------+   \    |
+---------+   |  \     |                  \   |    +----------+
              |   \    |                   \  |    | Foreign  |
              |    \   |                    \ |    | Mobile IP|
              |     \  |                   +-++-+  | Network  |
              |    +-+-+--+                | FA2|  | +------+ |
              +----+ LER3 +----------------+LER4+--+-|New MN| |
                   +---+--+                +----+  | +------+ |
                       |                           +----------+
                     +-+--+
                     | FN |
                     +----+

      Figure 2. The MPLS Network Architecture with Mobility Support
                  (Scenario 2 : Query Before Tunneling)


   Figure 2 shows the MPLS network architecture using Scenario 2 (Query
   Before Tunneling). In this scenario, the HA is attached at the LSR
   and is not capable to intercept IP packets. But, the registration
   procedure is the same with Scenario 1. According to geographical area
   and routing path, HA may cover more than one regional Mobile IP
   networks.

   The tunneling procedure of this model might be different from that of
   Scenario 1. When a FN at LER3 sends packets to a MN located in the
   foreign area, the ingress LER (LER3) has to decide the relevant
   forwarding path depending on routing information. There are three
   alternatives to forward IP packets.

      case (a) home IP address of a MN as default forwarding path
      case (b) HA address of the MN
      case (c) CoA address of the MN, that is, egress LER/FA as
               tunneling receive endpoint of MN

   For the case (a), the additional processing on the home LER is
   required since the UDP traffic tries to take the default path without
   reservation of label flow. In case (b), the HA address should be
   already known by all network elements and there is no advantage to
   locate at the LSR. It requires for further study.


Choi, et al.               Expires July 2001                   [Page 8] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


   It is preferable of case (c) that the forwarding path from ingress
   LER should be cut through the egress LER/FA, the CoA of the MN. For
   all the cases, the ingress LER should find forwarding path with
   relevant query process. The query process is depending on whether the
   destination is a mobile user or not. It may cause that this scenario
   is not applicable to IPv4 network without relevant procedure since
   the IPv4 address structure is not capable of identifying mobile
   terminal. For IPv6, it seems to be applicable when some address
   spaces are dedicated for mobile. One possible application for this
   scenario may be the MPLS-based IMT-2000 Network using Ipv6.

   For this scenario, it requires the query process to find the
   destination tunnel endpoints on the MPLS network. The LER decides
   whether destinations are for mobile application. And it tries to look
   up their label table for incoming packets. When the relevant port
   entries and labels are found, it sends them to the output port with a
   label header. If no entry is returned, it sends the query messages to
   the HA dealing with destination IP address. For the UDP traffic, it
   also requires the query process on destination address to assign the
   default label value. Then, the incoming IP packets may wait for
   several seconds to get the address of egress LER/FA.

   For the matters of QoS and traffic control, it should investigate
   whether the bandwidths between ingress LER and egress LER are
   available or not. With these concerns, the CR-LDP or RSVP-TE may be
   useful to take a relevant forwarding path.

   The detail discussions on Query Before Tunneling scenario require for
   further study.


2.3. Routing Considerations

   The routing on the MPLS network is depending on locations of HA and
   FA. In MPLS network, through flow classification, each flow may be
   different in grades of service. An LSP should meet certain QoS
   requirements of differential flows using CR-LDP or RSVP-TE.

   The detail discussions on routing issues of the MPLS network with
   mobility support are further study.


2.4. Interworking of existing Mobile IP network

   It requires for further study.









Choi, et al.               Expires July 2001                   [Page 9] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


3. Description of the Protocol

3.1. General Assumptions

   In this draft, the main issues of MPLS network architecture with
   mobility support are focused on the control procedure such as
   registration, agent discovery, LSP establishment and LSP Extension,
   etc. Agent advertisement and discovery within the scope of regional
   mobile IP network are beyond the scope of this document. We assume
   that the FAs support security associations

   We also assume on the mobile wireless IP networks that are divided
   into a number of cell regions according to geographical area. Each
   cell is covered by a Base Station (BS) which provides wireless IP
   access to the MN. The BS is connected to the LER to support mobility.


3.2. LSP Tunnels for Mobility Support

   There requires two types of LSP tunnels in the MLPS network with
   mobility support;

     - LSP tunnels between the ingress LER and HA
     - LSP tunnels between HA and egress LER/FA
     - Direct LSP tunnels between ingress LER and egress LER/FA
       (scenario 2)

   The existing LDP specification is well described to establish LSP
   tunnels for mobility. The address of HA and FA for LSP tunnels will
   be given by the Agent Discovery Procedure within the MPLS network.

   The LSP with QoS constraints will be contained in the CR-LDP or RSVP-
   TE specification [9],[10].


3.3. Registration of Mobile Node

   MN determines whether it is at home or in a foreign network when it
   receives agent advertisement messages broadcast by the mobility
   agents. If the MN determines that it is in a foreign network, the MN
   acquires a temporary CoA from FA and sends a registration request to
   FA. Since FA is an LER, it will analyze the incoming registration
   request message and get the destination address of the HA. Then FA
   updates its routing table and adds a host specific row with the label
   value of MN home address. In addition, it sets the outgoing port
   value of this entry to be the incoming port number from which it
   received the registration request.

MN                        FA1(LER2)                           HA
|                             |                                |
|---------------------------->|                                |


Choi, et al.               Expires July 2001                   [Page 10] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


| Broadcast Agent             |                                |
| Solicitation Message(ICMP)  |                                |
|<----------------------------|                                |
| Broadcast Agent             |                                |
| Advertisement Message(ICMP) |                                |
|                             |                                |
|---------------------------->|                                |
| MN Registration Request(UDP)|------------------------------->|
|                             | MN Registration Request (UDP)  |
|                             |                                |
|                             |<-------------------------------|
|<----------------------------| MN Registration Reply (UDP)    |
| MN Registration Reply (UDP) |                                |
|                             |                                |
|                             |    (no entry between HA and FA)|
|                             |<-------------------------------|
|                             | Label Request Message(CR-LDP)  |
|                             |                                |
|                             |------------------------------->|
|                             | Label mapping Message(CR-LDP)  |
|                             |                                |

        Figure 3. Registration of Mobile Node at the MPLS Network

   Based on the IP routing table, FA forwards the registration request
   message toward HA. The request message is forwarded to HA in a hop-
   by-hop manner using normal IP routing. When HA gets the registration
   request message and learns the CoA, it searches its label table to
   find the row with the MN home address as Forwarding Equivalence Class
   (FEC). Then, it will send a label request using CR-LDP to FA with the
   CoA as FEC. FA replies with an LDP label mapping message to HA. When
   this label mapping message arrives at HA, the LSP would have been
   established.

   After that, HA changes the row in its label table that uses the MN
   home address as FEC. It sets the empty out label and outgoing port
   entries to the values of out label and outgoing port of the LSP from
   HA to FA. In this way, HA can relay the packets destined to MN home
   address to its current location in the foreign network. Finally, HA
   sends a registration reply to FA along the LSP from HA to FA. When FA
   receives the registration reply, it records the incoming port number
   and in label value of the reply message. Then it adds a new row in
   its label table.


3.4. Agent Advertisement and Solicitation



Choi, et al.               Expires July 2001                   [Page 11] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


   Mobile agents (i.e., foreign agents and home agents) advertise their
   presence via Agent Advertisement messages. A mobile node may
   optionally solicit an Agent Advertisement message from any locally
   attached mobility agents through an Agent Solicitation message. A
   mobile node receives these Agent Advertisements and determines
   whether it is on its home network or a foreign network.

          FA+HA                                MN
           |                                   |
           |---------------------------------->|
           | Agent Advertisement Message       |
           |                                   |
           |<----------------------------------|
           | Agent Solicitation Message        |
           |                                   |

      Figure 4. Agent Discovery of Mobile Node at the MPLS Network

   If sent periodically, the nominal interval at which Agent
   Advertisements are sent SHOULD be 1/3 of the advertisement Lifetime
   given in the MPLS shim header. This allows a mobile node to miss
   three successive advertisements before deleting the agent from its
   list of valid agents. The actual transmission time for each
   advertisement SHOULD be slightly randomized [11] in order to avoid
   synchronization and subsequent collisions with other Agent
   Advertisements that may be sent by other agents.


3.5. Location Query of Mobile Node

   This procedure may be OPTIONALLY used for Scenario 2 (Query Before
   Tunneling) to find the direct short-cut path of egress LER or the
   default forwarding path of UDP traffic. When a MN moves to foreign
   mobile IP network, LER3 queries HA for the location of MN. HA
   responses to LER3 whether it has the information of it.

             LER3                                HA
             |---------------------------------->|
             |    Location Query Message         |
             |                                   |
             |<----------------------------------|
             |    Location Response Message      |
             |                                   |

       Figure 5. Location Query of Mobile Node at the MPLS Network




Choi, et al.               Expires July 2001                   [Page 12] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


   With Query information from HA, LER initiates the label binding
   process to the egress LER2/FA1 to a MN. After that, LER3 updates the
   row in its label table that uses the CoA of a MN as FEC. It sets a
   label value and outgoing port entries.

   In case that a FN sends IP packets to LER3 without any request
   message, LER3 searches for forwarding label entries to the
   destination MN. If not found, it sends the location query messages to
   HA to get the CoA of a MN. After that, it initiates the Label request
   message to the egress LER2/FA1 destined to a MN.


FN           LER3              HA   LSR         FA1(LER2)      MN
|             |                 |   |              |            |
|------------>|                 |   |              |            |
|User Packets |(no entry)       |   |              |            |
|             |---------------->|   |              |            |
|             |Location Query   |   |              |            |
|             |                 |   |              |            |
|             |<----------------|   |              |            |
|             |Location Response|   |              |            |
|             |                     |              |            |
|             |-------------------->|              |            |
|             | Label Request       |------------->|            |
|             |                     | Label Request|            |
|             |                     |<-------------|            |
|             |<--------------------| Label Mapping|            |
|             | Label Mapping       |              |            |
|             |                     |              |            |
|             |-------------------->|              |            |
|             | User Packets        |------------->|            |
|             |                     | User Packets |----------->|
|             |                     |              |User Packets|
|             |                     |              |            |

Figure 6. User Data Delivery using Location Query at the MPLS Network


3.6. LSP Extension for Handover

   There are two phases in handover scheme, we call it LSP Extension and
   LSP Recalculation. When a mobile node moves from Foreign IP Network
   FA1 to FA2, it sends a message to register the new FA. Signaling
   messages should be exchanged between old FA and new FA to extend the
   LSP tunnel. It extends the current LSP by establishing a LSP between
   current FA and new FA. During that time, old FA buffers all the
   packets from and to the mobile node. Once the LSP is established,
   packets are sent along the new path to the mobile node.


Choi, et al.               Expires July 2001                   [Page 13] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


_
                                 Existing
       +----+                       LSP  +----+
       | HA |    +------+   +------+     | FA1|   +--------+
_      |LER1+----+ LSR1 +---+ LSR2 +-----+LER2+---+ old MN |
       +--+-+    +------+   +------+     +--+-+   +--------+
           \                                |         |
            \                      Extended |         |
           +-+----+                   LSP   |         |
           | LER3 |                         |         |
           +--+---+                      +--+-+       V
              |                          | FA2|   +--------+
            +-+--+                       |LER4+---+ New MN |
            | FN |                       +----+   +--------+
            +----+

                  Figure 7. LSP Extension for Mobile IP


MN            New FA            Old FA          HA     ...    FN
 |               |               |               |             |
 |-------------->|               |               |             |
 | Reg. Request  |------------------------------>|             |
 |               |         Reg. Request          |             |
 |               |<------------------------------|             |
 |               |          Reg. Reply           |             |
 |               |               |               |             |
 |               |-------------->|               |             |
 |               |LSP Extension +|               |             |
 |               |  LSP Request  |               |             |
 |               |<--------------|               |             |
 |<--------------|LSP Ext. Reply+|               |             |
 | Reg. Reply    |  LSP Mapping  |               |             |
 |               |               |                             |
 |-------------->|               |                             |
 | User Messages |-------------->|                             |
 |               | User Messages |---------------------------->|
 |               |               | User Messages               |
 |               |               |                             |

                Figure 8. Message Sequence for LSP Extension


   The LSP extension procedures in Figure 8 are as follows.

     - MN moves to a new FA and sends a Registration Request message to
       New FA.
     - New FA sends a Registration Request message to HA.
     - HA sends Registration Reply message in response to the
       Registration Request.
     - If new FA receives Registration Reply message, new FA sends the
       Label Request and LSP Extension Message to old FA.


Choi, et al.               Expires July 2001                   [Page 14] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


     - A LSP is established between old FA and new FA when new FA
       receives Label Mapping message.
     - Then the new FA sends Registration Reply message to the MN


3.7. LSP Recalculation

   In LSP Recalculation, LSP tunnels between ingress LER and old FA are
   branched to the new FA. The LSR to perform branching function is
   usually referred to as the crossover LSR.
   After LSP Recalculation, the route between ingress LER and new FA can
   be optimized. Old path is torn down and new path is set up. LSP
   Recalculation is triggered by the MN. It can happen when the QoS of
   LSP tunnel is temporarily degraded.

   The major steps of LSP Recalculation involves:

     1. Determining the location of the crossover switch.
     2. Setting up a new branch LSP.
     3. Terminating the old branch LSP.


       +----+                           +----+
       | HA |    +------+   +------+    | FA1|   +--------+
_      |LER1+----+ LSR1 +---+ LSR2 |    |LER2|   | old MN |
       +--+-+    +------+   +----+-+    +----+   +--------+
           \                      \                  |
            \         Recalculated \                 |
           +-+----+       LSP       \                |
           | LER3 |                  \               |
           +--+---+                   \ +----+       V
              |                        \| FA2|   +--------+
            +-+--+                      +LER4+---+ New MN |
            | FN |                      +----+   +--------+
            +----+

                Figure 9. LSP Recalculation for Mobile IP




MN          New FA      Old FA      Crossover       HA   ...   FN
 |            |            |           LSR           |          |
 |Reg. Request|            |            |            |          |
 |----------->|             Reg. Request             |          |
 |            |------------------------------------->|          |
 |            |             Reg. Reply               |          |
 |            |<-------------------------------------|          |
 |            | LSP Ext. + |            |            |          |
 |            | LSP Request|            |            |          |
 |            |----------->|            |            |          |
 |            | LSP Mapping|            |            |          |
 |            |<-----------|            |            |          |

Choi, et al.               Expires July 2001                   [Page 15] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


 | Reg. Reply |            |            |            |          |
 |<-----------|            |            |            |          |
 |            |            |            |         Messages      |
 |            |            | Messages   |<----------------------|
 |            | Messages   |<-----------|            |          |
 | Messages   |<-----------|            |            |          |
 |<-----------|            |            |            |          |
 |            |            |            |            |          |
 | LSP Recal. |            |            |            |          |
 |----------->| Label Req. + LSP Recal. |            |          |
 |            |------------------------>|            |          |
 |            |    LSP Mapping          |            |          |
 |            |<------------------------|            |          |
 |            |            |            |            |          |
 |            |            |Label Rel.  |            |          |
 |            | Label Rel. |<-----------|            |          |
 |            |<-----------|            |            |          |
 |            | Label Rel. |            |            |          |
 |            |  Reply     | Label Rel. |            |          |
 |            |----------->|  Reply     |            |          |
 | LSP Recal. |            |----------->|            |          |
 |  Reply     |            |            |            |          |
 |<-----------|            |            |        Messages       |
 |            |        Messages         |<----------------------|
 | Messages   |<------------------------|                       |
 |<-----------|                         |                       |
 |            |                         |                       |
 |            |                         |                       |

            Figure 10. Message Sequence for LSP Recalculation


   The LSP Recalculation procedures in Figure 10 are as follows.

     - LSP Recalculation is triggered by the MN when QoS of channel of
       the mobile node is degraded.
     - New FA sends LSP Recalculation and Label Request message to the
       Crossover LSR when it receives LSP Recalculation message.
     - The Crossover LSR sends Label Mapping message to the new FA and
       releases existing LSP to the new FA via the old FA.
     - Then, FA sends LSP Recalculation message to the MN.








4. Required Messages and TLVs

4.1. Required Messages and TLVs


Choi, et al.               Expires July 2001                   [Page 16] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


   Any Messages, TLVs, and procedures not defined explicitly in this
   document are defined in the LDP Specification [3] and IP Mobility
   Support [4]. It can use Constraint-Based LSP Setup using LDP [2] as
   an informational document related to CR-LDP.


4.1.1. LDP PDUs

   Each LDP PDU is an LDP header followed by one or more LDP messages.
   The LDP header is:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Version                      |         PDU Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  LDP Identifier                     |                         |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Version
   Two octet unsigned integer containing version number

   PDU Length
   Two octet integer specifying the total length of this PDU in octets

   LDP Identifier
   Six octet field that uniquely identifies the label space of the
   sending LSR


4.1.2. Type-Length-Value Encoding

   LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of
   the information carried in LDP messages.

   An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify
   a Type and 2 bits to specify behavior when an LSR doesn't recognize
   the Type, followed by a 2 octet Length Field, followed by a variable
   length Value field.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|        Type               |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                             Value                             |
~                                                               ~
|                                                               |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Choi, et al.               Expires July 2001                   [Page 17] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  U bit
  Unknown TLV bit. As defined in [3]

  F bit
  Forward unknown TLV bit. As defined in [3]

  Type
  Encodes how the Value field is to be interpreted.

  Length
  Specifies the length of the Value field in octets.

  Value
  Octet string of Length octets that encodes information to be
  interpreted as specified by the Type field.


4.1.3. Message Format and Protocol Extensibility

   Mobility Support of Constraint-based LDP defines a set of new control
   messages. Currently, the following two message types are defined:

        0x3F01  Registration Request
        0x3F02  Registration Reply
        0x3F03  Location Query
        0x3F04  Location Response
        0x3F05  LSP Extension Request
        0x3F06  LSP Extension Reply
        0x3F07  LSP Recalculation Request
        0x3F08  LSP Recalculation Reply


   This draft defines a general Extension mechanism to allow optional
   information to be carried by LDP messages to support mobility. Each
   of these Extensions is encoded in the TLV format. Extensions allow
   variable amounts of information to be carried within each LDP =
Message.
   Currently, the following TLV are defined for Extensions appearing in
   LDP Mobility messages:

        0x3F11  Registration Request Data TLV
        0X3F12  Registration Reply Data TLV
        0x3F13  Location Query Data TLV Format
        0x3F14  Location Query Data TLV Format
        0x3F15  LSP Extension Request Date TLV Format
        0x3F16  LSP Extension Reply Data TLV Format
        0x3F17  LSP Recalculation Request Data TLV Format
        0x3F18  LSP Recalculation Reply Data TLV Format


4.2. Registration Message

Choi, et al.               Expires July 2001                   [Page 18] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000



   A mobile node registers with its home agent using a Registration
   Request message of LDP so that its home agent can create or modify a
   mobility binding for that mobile node (e.g., with a new lifetime).
   The Request may be relayed to the home agent by the foreign agent
   through which the mobile node is registering.


4.2.1. Registration Request Message Format

   The encoding for the Registration Request Message is:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|   Message Type (0x3F01)     |      Message Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Message ID                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                     Mandatory Parameters                      |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                     Optional Parameters                       |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U bit
   Unknown message bit.

   Message Type
   Identifies the type of message

   Message Length
   Specifies the cumulative length in octets of the Message ID,
   Mandatory Parameters, and Optional Parameters.

   Message ID
   32-bit value used to identify this message.

   Mandatory Parameters
   Variable length set of required message parameters.

   Optional Parameters
   Variable length set of optional message parameters.


4.2.1.1. Registration Request Data TLV Format

Choi, et al.               Expires July 2001                   [Page 19] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000



   Registration Request Data TLV is Mandatory Parameter of
   Registration Request Message. The encoding for Registration
   Request Data TLV is:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|       Type (0x3F11)       |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|B|D|M|G|V|     reserved      |          Lifetime             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Home Address                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Home Agent                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Care-of Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                         Identification                        +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U bit
   Unknown TLV bit.

   F bit
   Forward unknown TLV bit.

   Type
   0x3F11

   Length
   Specifies the length of the Value field in octets.

   S bit
   Simultaneous bindings. As described in [5].

   B bit
   Broadcast datagrams. As described in [5].

   D bit
   Decapsulation by mobile node. As described in [5].

   M bit
   Minimal encapsulation. As described in [5].

   G bit
   GRE encapsulation. As described in [5].

   V bit
   As described in [5].


Choi, et al.               Expires July 2001                   [Page 20] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


   resered
   Reserved bits; sent as zero

   Lifetime
   As described in [5].

   Home Address
   The IP address of the mobile node.

   Home Agent
   The IP address of the mobile node's home agent.

   Care-of Address
   The IP address for the end of the LSP tunnel.

   Identification
   As described in [5].


4.2.2. Registration Reply

   A mobility agent returns a Registration Reply message to a mobile
   node which has sent a Registration Request message. If   the mobile
   node is requesting service from a foreign agent, that foreign agent
   will receive the Reply from the home agent and subsequently relay it
   to the mobile node. The Reply message contains the necessary codes to
   inform the mobile node about the status of its Request, along with
   the lifetime granted by the home agent, as described in [5].


4.2.2.1. Registration Reply Message Format

   Registration Reply Message has following format:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|   Message Type (0x3F02)     |      Message Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Message ID                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                     Mandatory Parameters                      |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                     Optional Parameters                       |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Choi, et al.               Expires July 2001                   [Page 21] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000



   U bit
   Unknown message bit.

   Message Type
   Identifies the type of message

   Message Length
   Specifies the cumulative length in octets of the Message ID,
   Mandatory Parameters, and Optional Parameters.

   Message ID
   32-bit value used to identify this message.

   Mandatory Parameters
   Variable length set of required message parameters.

   Optional Parameters
   Variable length set of optional message parameters.


4.2.2.2 Registration Reply Data TLV Format

   The encoding for the Registration Reply Data TLV is:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|       Type (0x3F12)       |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code     |     reserved   |           Lifetime            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Home Address                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Home Agent                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                         Identification                        |
|                                                               +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U bit
   Unknown TLV bit.

   F bit
   Forward unknown TLV bit.

   Type
   0x3F12

   Length
   Specifies the length of the Value field in octets.


Choi, et al.               Expires July 2001                   [Page 22] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


   Code
   A value indicating the result of the Registration Request Message.

   Lifetime
   As described in [5].

   Home Address
   The IP address of the mobile node.

   Home Agent
   The IP address of the mobile node's home agent.

   Identification
   As described in [5].

   The following values are defined for use within the Code field.
   Registration successful:

   0 registration accepted
   1 registration accepted, but simultaneous mobility bindings
   unsupported

   Registration denied by the foreign agent and the home agent is
   specified in [5].


4.3. Agent Advertisement and Solicitation Messages

   The Agent Advertisement and Solicitation Messages are encapsulated by
   the MPLS shim header while a MN tries to discover the HA or FA
   through the MPLS network. (It may be optionally applied to Scenario
   2.)

   MPLS shim header

               20                          3   1       8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Label                     | Exp |S|     TTL       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Label      Some reserved value for Mobile IP

    Exp        experimental use

    S          bottom of stack

    TTL        the Time to live for all Agent Advertisements MUST be set
               to 1.



Choi, et al.               Expires July 2001                   [Page 23] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


   ICMP Agent Advertisement Message

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Num Addrs   |Addr Entry Size|           Lifetime            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Router Address[1]                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Preference Level[1]                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Router Address[2]                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Preference Level[2]                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    ICMP Fields:

      Type                  9

      Code                  1 (note: extended for Agent Discovery)

      Checksum              As described in [11].

      Num Addrs             The number of router addresses advertised
                            in this message.

      Addr Entry Size       As described in [11].

      Lifetime              The maximum number of seconds that the
                            router addresses may be considered valid.

      Router Address[i],    Mobile Agent=92s IP address.
      i=3D1..Num Addrs

      Preference Level[i],  As described in [11].
      i=3D1..Num Addrs


   ICMP Agent Solicitation Message

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |           Checksum            |

Choi, et al.               Expires July 2001                   [Page 24] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   ICMP Fields:

      Type                  10

      Code                  1 (note: extended for Agent Discovery)

      Checksum              As specified in [11].

      Reserved              Sent as 0; ignored on reception.


4.4. Location Query and Response Messages

   A LER wishing to send a packet to the mobile node for the first time
   must first discover the IP address of the mobile host's HA. The LER
   then issues a query to the HA, which returns the mobile host's
   Location as well as the remaining registration Lifetime. The LER
   cashes the mobile node's Location and uses the cached binding for
   subsequent packets destined to the mobile node. The LER Must refresh
   its binding cache by querying the HA again before the mobile node's
   remaining registration Lifetime expires.


4.4.1. Location Query Message Format

    The encoding for the Location Query Message is:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|   Message Type (0x3F03)     |      Message Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Message ID                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                     Mandatory Parameters                      |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                     Optional Parameters                       |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Choi, et al.               Expires July 2001                   [Page 25] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


   U bit
   Unknown message bit.

   Message Type
   Identifies the type of message

   Message Length
   Specifies the cumulative length in octets of the Message ID,
   Mandatory Parameters, and Optional Parameters.

   Message ID
   32-bit value used to identify this message.

   Mandatory Parameters
   Variable length set of required message parameters.

   Optional Parameters
   Variable length set of optional message parameters.


4.4.2. Location Query Data TLV Format

   Location Query Data TLV is Mandatory Parameter of Location Query
   Message. The encoding for Location Query Data TLV is:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|       Type (0x3F13)       |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Home Address                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U bit
   Unknown TLV bit.

   F bit
   Forward unknown TLV bit.

   Type
   Identifies the type of message

   Length
   Specifies the length of the Value field in octets.

   Home Address
   The IP address of the mobile node.


4.4.3. Location Response Message Format

    The encoding for the Location Response Message is:


Choi, et al.               Expires July 2001                   [Page 26] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|   Message Type (0x3F04)     |      Message Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Message ID                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                     Mandatory Parameters                      |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                     Optional Parameters                       |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U bit
   Unknown message bit.

   Message Type
   Identifies the type of message

   Message Length
   Specifies the cumulative length in octets of the Message ID,
   Mandatory Parameters, and Optional Parameters.

   Message ID
   32-bit value used to identify this message.

   Mandatory Parameters
   Variable length set of required message parameters.

   Optional Parameters
   Variable length set of optional message parameters.


4.4.4. Location Response Data TLV Format

   Location Response Data TLV is Mandatory Parameter of Location
   Response Message. The encoding for Location Response Data TLV is:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|       Type (0x3F14)       |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           reserved            |          Lifetime             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Home Address                         |

Choi, et al.               Expires July 2001                   [Page 27] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Care-of Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U bit
   Unknown TLV bit.

   F bit
   Forward unknown TLV bit.

   Type
   Identifies the type of message

   Length
   Specifies the length of the Value field in octets.

   Lifetime
   The number of seconds remaining before the registration is considered
   expired.

   Home Address
   The IP address of the mobile node.

   Care-of Address
   The IP address for the end of the LSP tunnel.


4.5. LSP Extension Message

   The encoding for the LSP Extension Message is:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|   Message Type              |      Message Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Message ID                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                     Mandatory Parameters                      |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                     Optional Parameters                       |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U bit
   Unknown message bit.

Choi, et al.               Expires July 2001                   [Page 28] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000



   Message Type
   Identifies the type of message

   In the case of LSP Extension Request, Message Type value is 0x3F05.
   If Message Type field valued is 0x3F06, then this message is LSP
   Extension Reply Message in response to LSP Extension Request.

   Message Length
   Specifies the cumulative length in octets of the Message ID,
   Mandatory Parameters, and Optional Parameters.

   Message ID
   32-bit value used to identify this message.

   Mandatory Parameters
   Variable length set of required message parameters.

   Optional Parameters
   Variable length set of optional message parameters.


4.5.1. LSP Extension Data TLV Format

   LSP Extension Data TLV is Mandatory Parameter of LSP Extension
   Message. The encoding for LSP Extension Data TLV is:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|       Type                |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Home Address                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Old FA Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         New FA Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   U bit
   Unknown TLV bit.

   F bit
   Forward unknown TLV bit.

   Type
   Identifies the type of message
   In the case of LSP Extension Request Data TLV, Type value is 0x3F15.
   If Type field valued is 0x3F16, then this TLV is LSP Extension Reply
   Data TLV in response to LSP Extension Request Data TLV.

   Length

Choi, et al.               Expires July 2001                   [Page 29] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


   Specifies the length of the Value field in octets.

   Home Address
   The IP address of the mobile node.

   Old FA Address
   The IP address of the old FA.

   New FA Address
   The IP address of the New FA.


4.6. LSP Recalculation Message

    The encoding for the LSP Recalculation Message is:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|   Message Type              |      Message Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Message ID                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                     Mandatory Parameters                      |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                     Optional Parameters                       |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U bit
   Unknown message bit.

   Message Type
   Identifies the type of message

   In the case of LSP Recalculation Request Message, Message Type value
   is 0x3F07. If Message Type field valued is 0x3F08, then this message
   is LSP Recalculation Reply Message in response to LSP Recalculation
   Request.

   Message Length
   Specifies the cumulative length in octets of the Message ID,
   Mandatory Parameters, and Optional Parameters.

   Message ID
   32-bit value used to identify this message.

Choi, et al.               Expires July 2001                   [Page 30] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000



   Mandatory Parameters
   Variable length set of required message parameters.

   Optional Parameters
   Variable length set of optional message parameters.


4.6.1. LSP Recalculation Data TLV Format

   LSP Recalculation Data TLV is Mandatory Parameter of LSP
   Recalculation Message. The encoding for LSP Recalculation Data TLV
   is:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|       Type                |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Home Address                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         New FA Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Crossover LSR Address                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   U bit
   Unknown TLV bit.

   F bit
   Forward unknown TLV bit.

   Type
   Identifies the type of message.
   In the case of LSP Recalculation Request Data TLV, Message Type value
   is 0x3F17. If Type field value is 0x3F18, then this TLV is LSP
   Recalculation Reply Data TLV in response to LSP Extension Request
   Data TLV.

   Length
   Specifies the length of the Value field in octets.

   Home Address
   The IP address of the mobile node.

   New FA Address
   The IP address of the new FA.

   Crossover LSR Address
   The IP address of the Crossover LSR.



Choi, et al.               Expires July 2001                   [Page 31] =0A=
=0C


Internet Draft      Draft-choi-mobileip-ldpext-00.txt      December 2000


5. IANA Considerations

   This draft does not create any new number spaces for IANA
   administration.


6. Security Considerations

   This document does not have any security concerns. The security
   requirements using this document are described in the referenced
   documents.


7. References


   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
       9, RFC 2026, October 1996.
   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997
   [3] Andersson L., et. al, =93LDP Specification,=94 =
<draft-ietf-mpls-ldp-
       11.txt>, Auguest 2000
   [4] Gustafsson E., et al., =93Mobile IP Regional Registration,=94 =
<draft-
       ietf-mobileip-reg-tunnel-03.txt, 13 July 2000
   [5] Perkins C., =93IP Mobility Support,=94 RFC2002, October 1996
   [6] Perkins C., =93IP Mobility Support for IPv4,=94 =
<draft-ietf-mobileip-
       rfc2002-bis-02.txt>, 13 July 2000
   [7] Perkins C., =93Minimal Encapsulation within IP,=94 RFC 2004, =
October
       1996
   [8] Ren Z., et al., =93Integration of Mobile IP and MPLS=94, <draft-
       zhong-mobile-ip-mpls-01.txt>, July 2000.
   [9] Jamoussi B., et al., =93Constraint-based LSP Setup using LDP,=94
       <draft-ietf-mpls-crl-ldp-04.txt>, July 2000
   [10] Awduche D. O., et al., =93REVP-TE: Extensions to RSVP for LSP
       Tunnels,=94 <draft-ietf-mpls-rsvp-lsp-tunnel-06.txt>, July 2000
   [11] Deering S., Editor, "ICMP Router Discovery Messages", RFC 1256,
       September 1991.
   [12] Gustafsson E., et al. "Mobile IP Regional Registration" work in
       progress, <draft-ietf-mobileip-reg-tunnel-03>. July 2000
   [13] Rivest R., "The MD5 Message-Digest Algorithm", RFC 1321 April
       1992













Choi, et al.               Expires July 2001                   [Page 32] =0A=
=0C



8. Author's Addresses

   Jun Kyun Choi
   Information and Communications University (ICU)
   58-4 Hwa Ahm Dong, Yusong, Taejon
   Korea 305-732
   Phone: +82-42-866-6122
   Email: jkchoi@icu.ac.kr

   Yoo Kyoung Lee
   Electronics and Telecommunication Research Institute (ETRI)
   161 Kajung Dong Yusong, Taejon
   Korea 305-305
   Phone: +82-42-860-6120
   Email: leeyk@etri.re.kr

   Sun Hee Yang
   Electronics and Telecommunication Research Institute (ETRI)
   161 Kajung Dong Yusong, Taejon
   Korea 305-305
   Phone: +82-42-860-5231
   Email: shyang@etri.re.kr

   Eun Ah Kim
   Electronics and Telecommunication Research Institute (ETRI)
   161 Kajung Dong Yusong, Taejon
   Korea 305-305
   Phone: +82-42-860-4820
   Email: eakim@etri.re.kr


9. Full Copyright Statement

   "Copyright (C) The Internet Society (date). 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.











 =0A=
=0C
------=_NextPart_000_0020_01C05043.383EE210
Content-Type: application/msword;
        name="draft-choi-mobileip-ldpext-00.DOC"
Content-Disposition: attachment;
        filename="draft-choi-mobileip-ldpext-00.DOC"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAUAEAAAAAAAAA
EAAAUgEAAAEAAAD+////AAAAAE0BAABOAQAATwEAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAOSAJBAAA8FK/AAAAAAAAEAAAAAAABAAA5BQBAA4AYmpiav3P/c8AAAAAAAAAAAAAAAAAAAAA
AAASBBYAWqYBAJ+lAACfpQAA3goBAAAAAAANAQAAAAAAAAAAAAD4BAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAF4TAAAAAAAAXhMAAF4T
AAAAAAAAXhMAAAAAAAB+EwAAAAAAAH4TAAAAAAAAfhMAACQAAAAAAAAAAAAAAKITAAAAAAAA5IYA
AAAAAADkhgAAAAAAAOSGAABQAAAANIcAAJQAAADIhwAApAEAAKITAAAAAAAAZMwAAFgCAAB4iQAA
AAAAAHiJAAA0AAAArIkAAAAAAACsiQAAAAAAAKyJAAAAAAAAv4oAAAAAAAC/igAAAAAAAL+KAAAA
AAAA48sAAAIAAADlywAAAAAAAOXLAAAAAAAA5csAAAAAAADlywAAAAAAAOXLAAAAAAAA5csAACQA
AAC8zgAAIAIAANzQAAB2AAAACcwAABUAAAAAAAAAAAAAAAAAAAAAAAAAfhMAAAAAAAC/igAAAAAA
AAAAAAAAAAAAAAAAAAAAAAC7igAABAAAAL+KAAAAAAAAv4oAAAAAAAC/igAAAAAAAAnMAAAAAAAA
mZsAAAAAAABeEwAAEAAAAG4TAAAQAAAArIkAAAAAAAAAAAAAAAAAAKyJAAAPAQAAHswAABYAAACZ
mwAAAAAAAJmbAAAAAAAAmZsAAAAAAAC/igAASgUAAH4TAAAAAAAArIkAAAAAAAB+EwAAAAAAAKyJ
AAAAAAAA48sAAAAAAAAAAAAAAAAAAJmbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAv4oAAAAAAADjywAAAAAAAJmbAADOBwAAmZsAAAAAAABnowAA
ngMAAFnGAACYAgAAfhMAAAAAAAB+EwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAocoAAAAAAACsiQAAAAAAAGyJAAAMAAAAsKs/k/FP
wAGiEwAAQnMAAOSGAAAAAAAACZAAAPYHAADxyAAASAAAAAAAAAAAAAAAr8oAADQBAAA0zAAAMAAA
AGTMAAAAAAAAOckAAGgBAABS0QAAAAAAAP+XAACaAwAAUtEAAAAAAAChygAADgAAAJmbAAAAAAAA
ohMAAAAAAACiEwAAAAAAAF4TAAAAAAAAXhMAAAAAAAB+EwAAAAAAAH4TAAAAAAAAAgDZAAAATVBM
UyBXb3JraW5nIEdyb3VwB0p1biBLeXVuIENob2kHB0ludGVybmV0IERyYWZ0B0lDVSAHB0RvY3Vt
ZW50OiBkcmFmdC1jaG9pLW1vYmlsZWlwLWxkcGV4dC0wMC50eHQHWW9vIEt5b3VuZyBMZWUHBwdF
VFJJBwcHU3VuIEhlZSBZYW5nBwcHRVRSSQcHB0V1biBBaCBLaW0HBwdFVFJJBwcHRGVjZW1iZXIg
MjAwMCAHBw0NRXh0ZW5zaW9uIG9mIExEUCBmb3IgTW9iaWxlIElQIFNlcnZpY2UNdGhyb3VnaCB0
aGUgTVBMUyBOZXR3b3JrDTxkcmFmdC1jaG9pLW1vYmlsZWlwLWxkcGV4dC0wMC50eHQ+DQ0NU3Rh
dHVzIG9mIHRoaXMgTWVtbw0NVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQg
aXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAg
b2YgUkZDMjAyNiBbAl0uIA0NVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQg
aXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAg
b2YgUkZDMjAyNiBleGNlcHQgdGhhdCB0aGUgcmlnaHQgdG8gcHJvZHVjZSBkZXJpdmF0aXZlIHdv
cmtzIGlzIG5vdCBncmFudGVkLiANDVRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQg
YW5kIGlzIE5PVCBvZmZlcmVkIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDEwIG9mIFJGQzIw
MjYsIGFuZCB0aGUgYXV0aG9yIGRvZXMgbm90IHByb3ZpZGUgdGhlIElFVEYgd2l0aCBhbnkgcmln
aHRzIG90aGVyIHRoYW4gdG8gcHVibGlzaCBhcyBhbiBJbnRlcm5ldC1EcmFmdCANDUludGVybmV0
LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5n
IFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuIE5v
dGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50
cyBhcyBJbnRlcm5ldC1EcmFmdHMuIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRz
IHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJl
cGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJdCBp
cyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC0gRHJhZnRzIGFzIHJlZmVyZW5jZSBtYXRl
cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iIA1U
aGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQgaHR0
cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0IA1UaGUgbGlzdCBvZiBJbnRl
cm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0IGh0dHA6Ly93
d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQ0NQWJzdHJhY3QNDVRoaXMgZG9jdW1lbnQgZGlzY3Vz
c2VzIGhvdyB0byBidWlsZCB0aGUgbGFyZ2Utc2NhbGUgbW9iaWxlIElQIG5ldHdvcmsgdGhyb3Vn
aCB0aGUgTVBMUyBuZXR3b3JrLiBPbmUgc21hbGwtc2NhbGUgbW9iaWxlIElQIG5ldHdvcmsgY291
bGQgYmUgY29ubmVjdGVkIHRvIG90aGVyIG5ldHdvcmtzIHRocm91Z2ggdGhlIE1QTFMgYmFja2Jv
bmUgbmV0d29yay4NSXQgcHJvcG9zZXMgdGhlIE1QTFMgbmV0d29yayBhcmNoaXRlY3R1cmUgdG8g
cHJvdmlkZSB0aGUgbGFyZ2Utc2NhbGUgbW9iaWxlIElQIG5ldHdvcmsuIFNwZWNpZmljYWxseSwg
aXQgcHJvcG9zZXMgdGhhdCB0aGUgbGFiZWwgZGlzdHJpYnV0aW9uIHByb3RvY29sIChMRFApIGNh
biBiZSBhcHBsaWVkIHRvIHNldCB1cCB0aGUgTGFiZWwgc3dpdGNoZWQgcGF0aCAoTFNQKSB0dW5u
ZWxzIGJldHdlZW4gdGhlIG1vYmlsZSBhZ2VudHMgKHRoYXQgaXMsIEZvcmVpZ24gQWdlbnRzIGFu
ZCBIb21lIEFnZW50cylbM10uIEl0IG1lYW5zIHRoYXQgdGhlIElQLWluLUlQIHR1bm5lbHMgY2Fu
IGJlIHJlcGxhY2VkIGJ5IG9uZSBvciBtdWx0aXBsZSBMYWJlbCBzd2l0Y2hlZCBwYXRocyAoTFNQ
cykgb24gdGhlIE1QTFMgbmV0d29yay4NDQ1Db252ZW50aW9ucw0NVGhlIGtleSB3b3JkcyAiTVVT
VCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCAiU0hPVUxE
IiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGlu
IHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMt
MjExOSBbAl0uDQ0NVGFibGUgb2YgQ29udGVudHMNDTEuIEludHJvZHVjdGlvbg0yLiBUaGUgTVBM
UyBOZXR3b3JrIEFyY2hpdGVjdHVyZSB3aXRoIE1vYmlsaXR5IFN1cHBvcnQNMi4xLiBBc3N1bXB0
aW9ucyBhbmQgUmVxdWlyZW1lbnRzDTIuMi4gTmV0d29yayBBcmNoaXRlY3R1cmUgYW5kIFNlcnZp
Y2UgU2NlbmFyaW9zDTIuMy4gUm91dGluZyBjb25zaWRlcmF0aW9ucw0yLjQuIEludGVyd29ya2lu
ZyBvZiBleGlzdGluZyBNb2JpbGUgSVAgbmV0d29yaw0zLiBEZXNjcmlwdGlvbiBvZiB0aGUgUHJv
dG9jb2wNMy4xLiBHZW5lcmFsIEFzc3VtcHRpb25zDTMuMi4gTFNQIFR1bm5lbHMgZm9yIE1vYmls
aXR5IFN1cHBvcnQNMy4zLiBSZWdpc3RyYXRpb24gb2YgTW9iaWxlIE5vZGUNMy40LiBBZ2VudCBB
ZHZlcnRpc2VtZW50IGFuZCBTb2xpY2l0YXRpb24NMy41LiBMb2NhdGlvbiBRdWVyeSBvZiBNb2Jp
bGUgTm9kZQ0zLjYuIExTUCBFeHRlbnNpb24gZm9yIEhhbmRvdmVyDTMuNy4gTFNQIFJlY2FsY3Vs
YXRpb24gICANNC4gUmVxdWlyZWQgTWVzc2FnZXMgYW5kIFRMVnMNNC4xLiBSZXF1aXJlZCBNZXNz
YWdlcyBhbmQgVExWcw00LjIuIFJlZ2lzdHJhdGlvbiBNZXNzYWdlDTQuMy4gQWdlbnQgQWR2ZXJ0
aXNlbWVudCBhbmQgU29saWNpdGF0aW9uIE1lc3NhZ2VzDTQuNC4gTG9jYXRpb24gUXVlcnkgYW5k
IFJlc3BvbnNlIE1lc3NhZ2VzDTQuNS4gTFNQIEV4dGVuc2lvbiBNZXNzYWdlDTQuNi4gTFNQIFJl
Y2FsY3VsYXRpb24gTWVzc2FnZQ01LiBJQU5BIENvbnNpZGVyYXRpb25zDTYuIFNlY3VyaXR5IENv
bnNpZGVyYXRpb25zDTcuIFJlZmVyZW5jZXMNOC4gQXV0aG9yJ3MgQWRkcmVzc2VzDTkuIEZ1bGwg
Q29weXJpZ2h0IFN0YXRlbWVudA0NDQ0NDQ0NDQ0NDQ0NDQ0NDTEuIEludHJvZHVjdGlvbg0NQSBt
b2JpbGUgbm9kZSBvZiBhIE1vYmlsZSBJUCBuZXR3b3JrIG1heSBiZSBjb25uZWN0ZWQgdG8gRm9y
ZWlnbiBNb2JpbGUgSVAgbmV0d29ya3Mgd2l0aCBhIGRpc3RhbmNlLiBUaGUgTVBMUyBuZXR3b3Jr
IGNhbiBwcm92aWRlIHRoZSBiYWNrYm9uZSBzb2x1dGlvbiBmb3IgaGlnaCBzcGVlZCBJUCBmb3J3
YXJkaW5nLiBUaGUgcmVsZXZhbnQgbGFiZWwgc3dpdGNoZWQgcGF0aHMgb24gdGhlIE1QTFMgbmV0
d29yayBjYW4gc3VwcG9ydCBwcm9wZXIgcXVhbGl0eS1vZi1zZXJ2aWNlIChRb1MpIHBhdGhzIGZv
ciBkaWZmZXJlbnRpYXRlZCBtb2JpbGUgSVAgc2VydmljZXMuIFRoaXMgZG9jdW1lbnQgcHJvcG9z
ZXMgdGhlIE1QTFMgbmV0d29yayBhcmNoaXRlY3R1cmUgYW5kIHR1bm5lbGluZyBwcm9jZWR1cmVz
IHRvIHN1cHBvcnQgdGhlIG1vYmlsZSBJUCBuZXR3b3JrLiBTaW1pbGFyIGNvbmNlcm5zIG9uIHRo
ZSBpbnRlZ3JhdGlvbiBvZiBNUExTIG5ldHdvcmsgYW5kIE1vYmlsZSBJUCBuZXR3b3JrIGFyZSBh
bHNvIGludmVzdGlnYXRlZCBpbiBbOF0uDQ1UaGUgTVBMUyBiYWNrYm9uZSBuZXR3b3JrIGNhbiBi
dWlsZCB0aGUgbGFyZ2Utc2NhbGUgbW9iaWxlIElQIG5ldHdvcmsuIEEgbW9iaWxlIElQIG5ldHdv
cmsgaXMgY29ubmVjdGVkIHRvIG90aGVyIG1vYmlsZSBJUCBuZXR3b3JrIHZpYSB0aGUgTGFiZWwg
RWRnZSBSb3V0ZXIgKExFUikuIFRvIHN1cHBvcnQgTW9iaWxlIElQIHNlcnZpY2VzLCBUaGUgTVBM
UyBuZXR3b3JrIGhhdmUgdG8gYWNjb21tb2RhdGUgRm9yZWlnbiBBZ2VudCBhbmQgSG9tZSBBZ2Vu
dC4gVGhlIExFUiBpcyBjYXBhYmxlIG9mIGZvcndhcmRpbmcgTW9iaWxlIElQIHBhY2tldHMgYnkg
ZW5jYXBzdWxhdGluZyB3aXRoIHJlbGV2YW50IGxhYmVsIGhlYWRlci4gVGhlIExFUiAoTGFiZWwg
RWRnZSBSb3V0ZXIpIHdvdWxkIGJlIGEgRm9yZWlnbiBBZ2VudCBvciBpdHMgY29ycmVzcG9uZGlu
ZyBub2RlLiBGb3IgbW9iaWxpdHkgc3VwcG9ydCwgdGhlIExFUiB3aWxsIGJlIGEgZ2F0ZXdheSBy
b3V0ZXIgZm9yIHRoZSBjb3JyZXNwb25kaW5nIG1vYmlsZSBJUCBuZXR3b3JrLiBUbyBzdXBwb3J0
IHRoZSBoaWVyYXJjaGljYWwgYXJjaGl0ZWN0dXJlLCB0aGUgR2F0ZXdheSBGQSBvciBSZWdpb25h
bCBGQSBjb3VsZCBiZSBkZWZpbmVkIG9uIHRoZSBNUExTIG5ldHdvcmsgWzRdLg0NRm9yIHRoZSBj
b250cm9sIHByb2NlZHVyZSwgdGhlIGxhYmVsIGRpc3RyaWJ1dGlvbiBwcm90b2NvbCAoTERQKSBt
YXkgYmUgZXh0ZW5kZWQgdG8gc2V0IHVwIHRoZSBMYWJlbCBzd2l0Y2hlZCBwYXRoIChMU1ApIHR1
bm5lbCBiZXR3ZWVuIHRoZSBtb2JpbGUgYWdlbnRzICh0aGF0IGlzLCBGb3JlaWduIEFnZW50cyBh
bmQgSG9tZSBBZ2VudHMpIHRocm91Z2ggdGhlIE1QTFMgbmV0d29yayBbM10uIFRoZSBJUC1pbi1J
UCB0dW5uZWxzIG9mIE1vYmlsZSBJUCBOZXR3b3JrIGNhbiBiZSBwcm92aWRlZCBieSB0aGUgb25l
IG9yIG11bHRpcGxlIExTUHMgdGhyb3VnaCB0aGUgTVBMUyBuZXR3b3JrLiBXaGVuIGEgbW9iaWxl
IG5vZGUgaXMgbW92aW5nIHRvIHRoZSBmb3JlaWduIGFyZWEsIHRoZSBleGlzdGluZyBMU1BzIG1h
eSBiZSBleHRlbmRlZCB3aXRob3V0IHNlcnZpY2UgaW50ZXJydXB0LiBUaGUgc2hvcnQtY3V0IExT
UHMgYmV0d2VlbiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIG1vYmlsZSBub2RlcyBtYXkgYmUgcmVj
YWxjdWxhdGVkIHRvIGF2b2lkIHRoZSBsb25nIGNhc2NhZGVkIGNvbm5lY3Rpb25zLg0NVGhlIEhv
bWUgQWdlbnQgY2FuIGJlIGltcGxlbWVudGVkIG9uIHRoZSByZWxldmFudCBNUExTIHJvdXRlcnMg
YWNjb3JkaW5nIHRvIGdlb2dyYXBoaWNhbCBhcmVhIGFuZCByb3V0aW5nIHBhdGguIFRoZXJlIG1h
eSBiZSB0d28gdHlwZXMgb2Ygc2NlbmFyaW9zIGFjY29yZGluZyB0byBsb2NhdGlvbiBvZiBIb21l
IEFnZW50IChIQSkuIFNjZW5hcmlvIDEgKHdlIGNhbGwgaXQsIFR1bm5lbCBFeHRlbnNpb24pIGlz
IGEgbmF0dXJhbCBleHRlbnNpb24gb2YgdGhlIGV4aXN0aW5nIG1vYmlsZSBJUCBwcm90b2NvbCB0
aHJvdWdoIHRoZSBNUExTIG5ldHdvcmsuIFRoZSBNUExTIG5ldHdvcmsgcHJvdmlkZXMgdGhlIExT
UCB0dW5uZWxzIHJlcGxhY2VkIGJ5IHRoZSBJUC1pbi1JUCB0dW5uZWxzLiBTY2VuYXJpbyAyICh3
ZSBjYWxsIGl0LCBRdWVyeSBCZWZvcmUgVHVubmVsaW5nKSBpcyB0aGF0IHRoZSBIQSBpcyBhdHRh
Y2hlZCBhdCB0aGUgTFNSIGxpa2UgYSBzZXJ2ZXIgc2luY2UgaXQgY291bGRuknQgaW50ZXJjZXB0
IHRoZSBpbmNvbWluZyBJUCBwYWNrZXRzIHRvIGZvcndhcmQgdGhlIGRlc3RpbmF0aW9uIEZBIGJl
bG9uZ2luZyB0byB0aGUgdmlzaXRpbmcgYXJlYSBvZiBhIG1vYmlsZSBub2RlLg0NU2NlbmFyaW8g
MSAoVHVubmVsIEV4dGVuc2lvbikgaXMgYmFzZWQgb24gdGhlIGV4aXN0aW5nIHNjZW5hcmlvIG9m
IE1vYmlsZSBJUCBzZXJ2aWNlIGFuZCB0aGUgSEEgc2hvdWxkIGJlIGxvY2F0ZWQgYXQgdGhlIExF
UiBbNV0sWzZdLiBJbiB0aGlzIHNjZW5hcmlvLCB0aGUgSVAtaW4tSVAgdHVubmVscyBiZXR3ZWVu
IEhBIGFuZCBGQSBjb3VsZCBiZSBkb25lIHdpdGggaGVscCBvZiB0aGUgTERQIG9wZXJhdGlvbi4g
VGhlcmUgaXMgbm8gYWRkaXRpb25hbCBjb25zdHJhaW50cyBvbiB0aGUgZXhpc3RpbmcgcHJvdG9j
b2xzIG9mIG1vYmlsZSBJUC4NDVNjZW5hcmlvIDIgKFF1ZXJ5IEJlZm9yZSBUdW5uZWxpbmcpIGlz
IHRoYXQgdGhlIEhBIGlzIGF0dGFjaGVkIG9yIGxvY2F0ZWQgYXQgdGhlIExhYmVsIFN3aXRjaGlu
ZyBSb3V0ZXIgKExTUikuIEl0IGFzc3VtZXMgdGhhdCB0aGUgTFNSIGlzIG5vdCBkaXJlY3RseSBj
b25uZWN0ZWQgdG8gdGhlIHJlZ2lvbmFsIG1vYmlsZSBJUCBuZXR3b3JrIGFuZCB0aGUgSEEgZG9l
c26SdCBiZSBjYXBhYmxlIHRvIGludGVyY2VwdCB0aGUgbW9iaWxlIElQIHBhY2tldHMgZm9yIHR1
bm5lbGluZy4gSW4gdGhpcyBjYXNlLCB0aGUgc2ltaWxhciBzY2VuYXJpbyB3aXRoIHRoZSBleGlz
dGluZyBjZWxsdWxhciBvciBJTVQtMjAwMCBuZXR3b3JrIHVzaW5nIGhvbWUgbG9jYXRpb24gcmVn
aXN0ZXIvdmlzaXQgbG9jYXRpb24gcmVnaXN0ZXIgKEhMUi9WTFIpIGNhbiBiZSBhcHBsaWVkLiBU
aGUgaW5ncmVzcyBMRVIgbWF5IHF1ZXJ5IHRoZSBjYXJlLW9mLWFkZHJlc3MgKENvQSkgb2YgdGhl
IGVncmVzcyBMRVIvRkEgZnJvbSB0aGUgSEEgdG8gZmluZCB0aGUgZGlyZWN0IHNob3J0LWN1dCBw
YXRoLiBUaGUgZm9yd2FyZGluZyBwYXRoIHNob3VsZCBiZSBwcmUtY2FsY3VsYXRlZCBieSBxdWVy
eSBwcm9jZXNzLiBUaGUgY2FjaGUgaW1wb3NpdGlvbiBvciBsYWJlbCBiaW5kaW5nIG9wZXJhdGlv
biBtYXkgYmUgZG9uZSBhdCB0aGUgTEVSL0ZBLg0NVG8gZGVsaXZlciB0aGUgbW9iaWxlIElQIHBh
Y2tldHMgdGhyb3VnaCB0aGUgTVBMUyBuZXR3b3JrLCBpdCByZXF1aXJlcyB0aGUgSVAgZW5jYXBz
dWxhdGlvbiBbN10uIEZhciBmcm9tIGhvbWUgbG9jYXRpb24sIHRoZSBtb2JpbGUgbm9kZSBzaG91
bGQgYmUgcmVnaXN0ZXJlZCB0byB0aGUgZm9yZWlnbiBMRVIgd2l0aCBwcm9wZXIgYWdlbnQgZGlz
Y292ZXJ5IHByb2Nlc3MuIFRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBzaG91bGQgYmUgYWxzbyBu
ZWVkZWQgYmV0d2VlbiB0aGUgSEEgYW5kIHRoZSBjb3JyZXNwb25kaW5nIEZBIHRocm91Z2ggdGhl
IE1QTFMgbmV0d29yay4gV2hpbGUgYSBub2RlIHRyaWVzIHRvIGNhbGwgdGhlIG1vYmlsZSBub2Rl
LCBkYXRhIGZvcndhcmRpbmcgcGF0aCB3aXRoIGhlbHAgb2YgSEEgc2hvdWxkIGJlIGVzdGFibGlz
aGVkIGJldHdlZW4gdGhlIHNvdXJjZSBMRVIgYW5kIHRoZSBkZXN0aW5hdGlvbiBMRVJzLiBUaGUg
bGFiZWwgc3dpdGNoZWQgcGF0aCAoTFNQKSBieSB0aGUgTERQIG9wZXJhdGlvbiB3b3VsZCBlbmFi
bGUgdG8gbGFiZWwgdGhlIElQIHBhY2tldHMgYW5kIGZvcndhcmRzIHRoZW0gYXQgdGhlIGRlc3Rp
bmF0aW9uIG1vYmlsZSBub2RlIHZpYSB0aGUgTVBMUyBuZXR3b3JrLg0NDTIuIFRoZSBNUExTIE5l
dHdvcmsgQXJjaGl0ZWN0dXJlIHdpdGggTW9iaWxpdHkgU3VwcG9ydA0NMi4xLiBBc3N1bXB0aW9u
cyBhbmQgUmVxdWlyZW1lbnRzDQ1JbiBvcmRlciB0byBwcm92aWRlIHRoZSBiYWNrYm9uZSBzb2x1
dGlvbiBmb3IgTW9iaWxlIElQIG5ldHdvcmssIGl0IGNvbnNpZGVycyB0aGUgZm9sbG93aW5nIGFz
c3VtcHRpb25zIG9uIHRoZSBNUExTIG5ldHdvcmsuDQ0tIFRoZXJlIGlzIG5vIGFkZGl0aW9uYWwg
cmVxdWlyZW1lbnRzIG9uIHRoZSBleGlzdGluZyBtb2JpbGUgSVAgcHJvdG9jb2wgc3VjaCBhcyBh
Z2VudCBkaXNjb3ZlcnksIHJlZ2lzdHJhdGlvbiwgYW5kIHJvdXRpbmcuDS0gQWxsIHRoZSByZWdp
b25hbCBtb2JpbGUgSVAgbmV0d29ya3Mgc2hvdWxkIGJlIGNvbm5lY3RlZCBhdCB0aGUgTEVSIHdo
aWNoIHdpbGwgYmUgYSBleHRlcm5hbCBnYXRld2F5IHJvdXRlciB0byBjb21tdW5pY2F0ZSB0aGUg
ZXh0ZXJuYWwgd29ybGQuIA0tIEluIHRoZSBNUExTIGJhY2tib25lIG5ldHdvcmssIGFsbCB0aGUg
TEVScyBhcmUgZXF1aXBwZWQgd2l0aCBGQSB0byBpZGVudGlmeSB0aGUgdmlzaXRpbmcgbW9iaWxl
IG5vZGVzLiBJbiBjYXNlIHRoYXQgYSBudW1iZXIgb2YgRkFzIGFyZSBpbiBhIE1vYmlsZSBJUCBu
ZXR3b3JrLCB0aGUgRkEgYXR0YWNoZWQgdG8gdGhlIExFUiBoYXMgYSByZXNwb25zaWJpbGl0eSB0
byBjb21tdW5pY2F0ZSB0byB0aGUgZXh0ZXJuYWwgd29ybGQuDS0gVGhlIEhBIHNob3VsZCBiZSBs
b2NhdGVkIGF0IHRoZSBMRVIgb3IgdGhlIExTUi4gSWYgYSBzbWFsbC1zY2FsZSBtb2JpbGUgSVAg
bmV0d29yayBhbHJlYWR5IGhhcyBhIG51bWJlciBvZiBIQXMgdG8gY292ZXIgdGhlaXIgb3duIHJl
Z2lvbmFsIGFyZWEsIGl0IHNob3VsZCBkaXNjcmltaW5hdGUgZnJvbSB0aGUgSEFzIGludGVyZmFj
ZWQgdG8gdGhlIE1QTFMgbmV0d29yay4gVGhlIHJlbGV2YW50IHJlZ2lzdHJhdGlvbiBwcm9jZWR1
cmUgaXMgcmVxdWlyZWQgZm9yIHRoZSBtb2JpbGUgSVAgbmV0d29yayBvbiBhIG51bWJlciBvZiBI
QS4gQSBtb2JpbGUgbm9kZSBzaG91bGQgcmVnaXN0ZXIgdGhlIEhBIGludGVyZmFjZWQgdG8gdGhl
IE1QTFMgbmV0d29yayB3aGlsZSBtb3ZpbmcgdG8gZXh0ZXJuYWwgd29ybGQuIEl0IGNhbiBleHRl
bmQgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZWR1cmUgb2YgbW9iaWxlIElQIHNlcnZpY2UgWzVdLFs2
XS4NLSBUaGUgZm9yd2FyZGluZyBwcm9jZXNzIG9uIHRoZSBNUExTIG5ldHdvcmsgc2hvdWxkIGJl
IHRha2VuIG9uIHRoZSBkYXRhZ3JhbSBJUCB0cmFmZmljICh0aGUgVURQIHRyYWZmaWMpIGFzIHdl
bGwgYXMgdGhlIHN0cmVhbS1saWtlIElQIHRyYWZmaWMgKHRoZSBUQ1AgdHJhZmZpYykuDQ1EZXBl
bmRpbmcgb24gdGhlIGxvY2F0aW9uIG9mIEhBIG9uIHRoZSBNUExTIG5ldHdvcmssIHRoZSBmb2xs
b3dpbmcgYXNzdW1wdGlvbnMgYXJlIHJlcXVpcmVkLiANDS0gSW4gU2NlbmFyaW8gMSAoVHVubmVs
IEV4dGVuc2lvbiksIGFsbCB0aGUgTEVScyBoYXZlIHRvIG9wZXJhdGUgdGhlIEhBLiBJdCBtZWFu
cyB0aGF0IGEgbW9iaWxlIG5vZGUgc2hvdWxkIGJlIGlkZW50aWZpZWQgYm90aCBmcm9tIHRoZSBI
QSBhbmQgdGhlIEZBIGF0IHZpc2l0aW5nIGFyZWEgd2hpbGUgbW92aW5nIHRvIGZvcmVpZ24gYXJl
YSBbNV0sWzZdLg0tIFdoZW4gYSBub2RlIHNlbmRzIHRoZSBJUCBwYWNrZXRzIHRvIHRoZSBtb2Jp
bGUgbm9kZSwgdGhlIExFUiB3aXRoIEhBIGludGVyY2VwdHMgYW5kIGZvcndhcmQgdGhlbSB0byB0
aGUgY29ycmVzcG9uZGluZyBMRVIvRkEgb24gdGVtcG9yYXJpbHkgdmlzaXRpbmcgYXJlYS4NDS0g
SW4gU2NlbmFyaW8gMiAoUXVlcnkgQmVmb3JlIFR1bm5lbGluZyksIHRoZSBIQSBpcyBub3QgbG9j
YXRlZCBhdCB0aGUgaG9tZSBMRVIuIEl0IG1lYW5zIHRoYXQgdGhlIEhBIGNvdWxkbpJ0IGludGVy
Y2VwdCBJUCBwYWNrZXRzLiBGb3IgdGhpcyBzY2VuYXJpbywgd2UgYXNzdW1lIHRoYXQgdGhlIGRh
dGEgZm9yd2FyZGluZyBwYXRocyBzaG91bGQgYmUgcHJlLWNhbGN1bGF0ZWQgYXQgdGhlIG9yaWdp
bmF0aW5nIExFUi4gV2hlbiBhIG5vZGUgc2VuZHMgSVAgcGFja2V0cyB0byB0aGUgZGVzdGluYXRp
b24gbW9iaWxlIElQIG5vZGUsIHRoZSBpbmdyZXNzIExFUiBoYXMgdG8gZGVjaWRlIHdoZXRoZXIg
Zm9yd2FyZGluZyB0byBob21lIGFyZWEgb3Igbm90LiBPdGhlcndpc2UsIGl0IGhhdmUgdG8gcXVl
cnkgZnJvbSB0aGUgSEEgdG8gZ2V0IHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBkZXN0aW5hdGlvbiBM
RVIvRkEgYXQgYSB0ZW1wb3JhcmlseSB2aXNpdCBhcmVhLg0NDTIuMi4gTmV0d29yayBBcmNoaXRl
Y3R1cmUgYW5kIFNlcnZpY2UgU2NlbmFyaW9zDQ1UaGUgTVBMUyBuZXR3b3JrIHRvIHN1cHBvcnQg
bW9iaWxlIElQIHNlcnZpY2UgZG9lc26SdCB1c2UgSVAgaW4gSVAgZW5jYXBzdWxhdGlvbi4gVGhl
IGxhYmVsIHN3aXRjaGVkIHBhdGggKExTUCkgdHVubmVsIHByb3ZpZGVzIGEgbG93ZXIgbGF5ZXIg
dHVubmVsaW5nIHNjaGVtZSBpbmRlcGVuZGVudCBvbiBoaWdoIGxheWVyIGFwcGxpY2F0aW9ucy4g
SXQgbm90ZXMgdGhhdCB0aGUgSVAtaW4tSVAgdHVubmVsaW5nIHV0aWxpemVzIHRoZSBsYXllciAz
IGZvcndhcmRpbmcgY2FwYWJpbGl0eSBpbiBJUCByb3V0aW5nLiBUaGUgaW5ncmVzcyBMRVIgZm9y
d2FyZHMgSVAgcGFja2V0cyBhbGwgdGhlIHdheSB0byB0aGUgSEEgdG8gdGhlIGVncmVzcyBMRVIg
dG8gdGhlIGZvcmVpZ24gbW9iaWxlIG5vZGUuIFRoZSB3aG9sZSBmb3J3YXJkaW5nIHByb2Nlc3Mg
aXMgZG9uZSBhdCB0aGUgTVBMUyBsYXllci4gVGhlIEhBIGRvZXNuJ3QgbmVlZCB0byBpbnZvbHZl
IHRoZSBJUCBsYXllciBmb3J3YXJkaW5nIHRvIGEgbW9iaWxlIG5vZGUuDQ1TaW5jZSBsYWJlbCBo
ZWFkZXIgaXMgbXVjaCBzbWFsbGVyIHRoYW4gSVAgZW5jYXBzdWxhdGlvbiBoZWFkZXIsIHRoZSBo
ZWFkZXIgb3ZlcmhlYWQgZnJvbSBIQSB0byBGQSBpcyBhbHNvIHJlZHVjZWQuIEl0IGNhbiBpbXBy
b3ZlIHRoZSBzY2FsYWJpbGl0eSBvZiBtb2JpbGUgSVAgcHJvdG9jb2wuIE1vcmVvdmVyLCBhbiBM
U1Agc2F0aXNmeWluZyB0aGUgcXVhbGl0eS1vZi1zZXJ2aWNlIChRb1MpIHJlcXVpcmVtZW50cyBh
bmQgdHJhZmZpYyBlbmdpbmVlcmluZyBjb3VsZCBiZSBzZXQgdXAgd2l0aCBDb25zdHJhaW50LUJh
c2VkIExhYmVsIERpc3RyaWJ1dGlvbiBQcm90b2NvbCAoQ1ItTERQKSBvciBSU1ZQLVRFIFs5XSxb
MTBdLg0NRmlndXJlIDEgc2hvd3MgdGhlIE1QTFMgbmV0d29yayBhcmNoaXRlY3R1cmUgdXNpbmcg
U2NlbmFyaW8gMSAoVHVubmVsIEV4dGVuc2lvbikuIEluIHRoaXMgc2NlbmFyaW8gdGhlIEhBIGlz
IGxvY2F0ZWQgYXQgdGhlIExFUjEgYW5kIGhhcyBhIGNhcGFiaWxpdHkgdG8gaW50ZXJjZXB0IElQ
IHBhY2tldHMgZm9yIGEgbW9iaWxlIG5vZGUuIFdoZW4gYSBtb2JpbGUgbm9kZSBmcm9tIHRoZSBM
RVIxL0hBIGFyZWEgaXMgdGVtcG9yYXJpbHkgbW92aW5nIHRvIHRoZSBMRVIyIGFyZWEsIHRoZSBy
ZWdpc3RyYXRpb24gaXMgcmVxdWlyZWQgdG8gSEEgdmlhIExFUjIvRkEyLiBXaGVuIGEgbm9kZSBh
dCBMRVIzIHNlbmRzIElQIHBhY2tldHMgdG8gYSBjdXJyZW50IG1vYmlsZSBub2RlLCB0aGUgTFNQ
IHR1bm5lbHMgd291bGQgYmUgZXN0YWJsaXNoZWQgZnJvbSBMRVIzIHRvIExFUjEgYW5kIGNhc2Nh
ZGluZyBmcm9tIExFUjEgdG8gTEVSMi4gVGhlIHJlbGV2YW50IExEUCBvcGVyYXRpb25zIHdpbGwg
YmUgdGFrZW4gd2l0aCBhc3NvY2lhdGlvbnMgb2YgRm9yd2FyZGluZyBFcXVpdmFsZW5jZSBDbGFz
cyAoRkVDKS4gV2hlbiBhIG1vYmlsZSBub2RlIGlzIG1vdmluZyB0byB0aGUgTEVSNC9GQTIgYXJl
YSBkdXJpbmcgYWN0aXZlIHNlcnZpY2UgdGltZSwgdGhlIExTUCB0dW5uZWwgZnJvbSBMRVIxIHRv
IExFUjIgc2hvdWxkIGJlIGV4dGVuZGVkIG9yIHJlLWNvbmZpZ3VyZWQgdG8gTEVSNCB3aXRoIHVw
ZGF0ZSBvbiBIQSwgRkExIGFuZCBGQTIuIFRoZSBzZWFtbGVzcyBMU1AgdHVubmVsIHRvIExFUjQg
bWF5IGJlIHJlcXVpcmVkIGZvciB0aGUgcmVhbC10aW1lIGFwcGxpY2F0aW9ucy4NDVRvIGVuY2Fw
c3VsYXRlIElQIHBhY2tldHMgd2l0aCBhIE1QTFMgaGVhZGVyLCB0aGUgZGVzdGluYXRpb24gYWRk
cmVzcyBvZiB0aGUgTVBMUyBoZWFkZXIgaXMgaW5pdGlhbGx5IHRoZSBMRVIyLiBUaGUgTVBMUyBs
YWJlbCBzdGFjayBvcGVyYXRpb24gbWF5IGN1dCB0aHJvdWdoIHRoZSBjb3JyZXNwb25kaW5nIGFk
ZHJlc3Mgb2YgdGhlIHR1bm5lbCdzIHJlY2VpdmUgZW5kcG9pbnQuIElmIHRoZSBpbmdyZXNzIHBv
aW50IG9mIHRoZSBMU1AgdHVubmVsIHdpc2hlcyB0byBwdXQgYSBsYWJlbGVkIHBhY2tldCBpbnRv
IHRoZSBNUExTIG5ldHdvcmssIGl0IHNob3VsZCByZXBsYWNlIHRoZSBsYWJlbCB2YWx1ZSBhdCB0
aGUgdG9wIG9mIHRoZSBzdGFjayB3aXRoIGEgbGFiZWwgdmFsdWUgdGhhdCB3YXMgZGlzdHJpYnV0
ZWQgdG8gaXQgYnkgdGhlIHR1bm5lbCdzIHJlY2VpdmUgZW5kcG9pbnQuIFRoZW4gaXQgbXVzdCBw
dXNoIG9uIHRoZSBsYWJlbCB3aGljaCBjb3JyZXNwb25kcyB0byB0aGUgdHVubmVsIGl0c2VsZiwg
YXMgZGlzdHJpYnV0ZWQgdG8gaXQgYnkgdGhlIG5leHQgaG9wIGFsb25nIHRoZSB0dW5uZWwuIFRv
IGFsbG93IHRoaXMsIHRoZSB0dW5uZWwgZW5kcG9pbnRzIHNob3VsZCBiZSBleHBsaWNpdCBsYWJl
bCBkaXN0cmlidXRpb24gcGVlcnMuDQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSsNICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfCBGb3JlaWduICB8DSAgICAgICAgICAgICAgKy0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgIHwgTW9iaWxlIElQfA0gICAgICAgICAgICAg
IHwgICAgICBUaGUgTVBMUyBOZXR3b3JrICAgICAgKy0rLS0rICB8IE5ldHdvcmsgIHwNICAgICAg
ICAgICAgICB8ICAgIHdpdGggTW9iaWxpdHkgU3VwcG9ydCAgIHwgRkExfCAgfCArLS0tLS0tKyB8
DSstLS0tLS0tLS0rICstLS0tKyAgICAgICAgICAgICAgICAgICAgICAgIC98TEVSMnwtLSstfG9s
ZCBNTnwgfA18SG9tZSAgICAgfCB8IEhBIHwgICstLS0tLS0rICArLS0tLS0tKyAgIC8gKy0tKy0r
ICB8ICstLS0tLS0rIHwNfE1vYmlsZSBJUCstK0xFUjF8LS18IExTUjEgKy0tKyBMU1IyIHwtLSsg
ICAgIHwgICAgKy0tLS0tLS0tLS0rDXxOZXR3b3JrICB8IHwtLS0tKyAgKy0tLS0tLSsgICstLS0t
LS0rICAgXCAgICB8ICAgICANKy0tLS0tLS0tLSsgICB8ICBcICAgICB8ICAgICAgICAgICAgICAg
ICAgXCAgIHwgICAgKy0tLS0tLS0tLS0rDSAgICAgICAgICAgICAgfCAgIFwgICAgfCAgICAgICAg
ICAgICAgICAgICBcICB8ICAgIHwgRm9yZWlnbiAgfA0gICAgICAgICAgICAgIHwgICAgXCAgIHwg
ICAgICAgICAgICAgICAgICAgIFwgfCAgICB8IE1vYmlsZSBJUHwNICAgICAgICAgICAgICB8ICAg
ICBcICB8ICAgICAgICAgICAgICAgICAgICstKystKyAgfCBOZXR3b3JrICB8DSAgICAgICAgICAg
ICAgfCAgICArLSstKy0tKyAgICAgICAgICAgICAgICB8IEZBMnwgIHwgKy0tLS0tLSsgfA0gICAg
ICAgICAgICAgICstLS0tfCBMRVIzIHwtLS0tLS0tLS0tLS0tLS0tfExFUjR8LS0rLXxOZXcgTU58
IHwNIAkgICAgICAgICAgICstLS0rLS0rICAgICAgICAgICAgICAgICstLS0tKyAgfCArLS0tLS0t
KyB8DSAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICst
LS0tLS0tLS0tKw0gICAgICAgICAgICAgICAgICAgICArLSstLSsNICAgICAgICAgICAgICAgICAg
ICAgfCBGTiB8DSAgICAgICAgICAgICAgICAgICAgICstLS0tKw0NTEVSOiBMYWJlbCBFZGdlIFJv
dXRlcg1MU1I6IExhYmVsIFN3aXRjaGluZyBSb3V0ZXINSEE6IEhvbWUgQWdlbnQNRkE6IEZvcmVp
Z24gQWdlbnQNTU46IE1vYmlsZSBOb2RlDUZOOiBGaXhlZCBOb2RlDQ1GaWd1cmUgMS4gVGhlIE1Q
TFMgTmV0d29yayBBcmNoaXRlY3R1cmUgd2l0aCBNb2JpbGl0eSBTdXBwb3J0IA0oU2NlbmFyaW8g
MSA6IFR1bm5lbCBFeHRlbnNpb24pDQ0NSW4gdGhpcyBzY2VuYXJpbywgdGhlIGZ1bmN0aW9ucyBv
ZiBjb3JyZXNwb25kZW50IGFnZW50cywgRkEsIGNhbiBiZSBsb2NhdGVkIGluIHRoZSBMRVJzLiBU
aGUgTFNQcyBjYW4gYmUgc2V0dXAgdGhlIHNhbWUgd2F5IGFzICJ0dW5uZWxzIiBhcmUgc2V0dXAg
YmV0d2VlbiBjb3JyZXNwb25kZW50IGFnZW50cyBhbmQgZm9yZWlnbiBhZ2VudHMuIFNpbmNlIGFu
IExTUCBjYW4gYmUgc2V0dXAgYmV0d2VlbiBhIGNvcnJlc3BvbmRlbnQgYWdlbnQgYW5kIGEgZm9y
ZWlnbiBhZ2VudCAodGhlIExFUnMpLCB0aGlzIGFsbG93cyBmb3IgdHJhZmZpYyBhZ2dyZWdhdGlv
biBiZXR3ZWVuIHRoZSBMRVJzLiBJbiBhZGRpdGlvbiBpdCBhbGxvd3MgY29uc3RyYWluZWQgYmFz
ZWQgcm91dGluZyBhbmQgdGhlIFFvUyBwYXRoIGJldHdlZW4gdGhlIGFnZW50cyBjYW4gYmUgZ3Vh
cmFudGVlZC4gVGhlIGVzdGFibGlzaG1lbnQgb2YgdGhlc2UgTFNQcyBjYW4gYmUgdHJpZ2dlcmVk
IGJ5IHRoZSBCaW5kaW5nIFVwZGF0ZSBtZXNzYWdlcywgYnkgZGF0YSB0cmFuc21pdHRlZCwgY29u
ZmlndXJlZCBhIHByaW9yaSBvciBieSBvdGhlciBtZWFucy4NDUluIHRoZSByZWdpc3RyYXRpb24g
cHJvY2VkdXJlLCB0aGUgbW9iaWxlIG5vZGUgKE1OKSBkZXRlcm1pbmVzIHdoZXRoZXIgaXQgaXMg
YXQgaG9tZSBvciBpbiBhIGZvcmVpZ24gbmV0d29yayB3aGVuIGl0IHJlY2VpdmVzIGFnZW50IGFk
dmVydGlzZW1lbnQgbWVzc2FnZXMgYnJvYWRjYXN0IGJ5IHRoZSBtb2JpbGl0eSBhZ2VudHMuIElm
IHRoZSBNTiBkZXRlcm1pbmVzIHRoYXQgaXQgaXMgaW4gYSBmb3JlaWduIG5ldHdvcmssIHRoZSBN
TiBhY3F1aXJlcyBhIHRlbXBvcmFyeSBDb0EgZnJvbSBGQSBhbmQgc2VuZHMgYSByZWdpc3RyYXRp
b24gcmVxdWVzdCB0byBGQS4gU2luY2UgRkEgaXMgYW4gZWRnZSBMRVIsIGl0IHdpbGwgYW5hbHl6
ZSB0aGUgaW5jb21pbmcgcmVnaXN0cmF0aW9uIHJlcXVlc3QgbWVzc2FnZSBhbmQgZ2V0IHRoZSBk
ZXN0aW5hdGlvbiBhZGRyZXNzIG9mIHRoZSByZXF1ZXN0LiBUaGVuLCBGQSB1cGRhdGVzIGl0cyBy
b3V0aW5nIHRhYmxlIHdpdGggdGhlIHZhbHVlIG9mIE1OIGhvbWUgYWRkcmVzcy4gSW4gYWRkaXRp
b24sIGl0IHNldHMgdGhlIG91dGdvaW5nIHBvcnQgdmFsdWUgb2YgdGhpcyBlbnRyeSB0byBiZSB0
aGUgaW5jb21pbmcgcG9ydCBudW1iZXIgZnJvbSB3aGljaCBpdCByZWNlaXZlZCB0aGUgcmVnaXN0
cmF0aW9uIHJlcXVlc3QuIEJhc2VkIG9uIHRoZSBJUCByb3V0aW5nIHRhYmxlLCBGQSBmb3J3YXJk
cyB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QgbWVzc2FnZSB0b3dhcmQgSEEuDQ1UaGUgcmVnaXN0
cmF0aW9uIHJlcXVlc3QgbWVzc2FnZSBpcyBmb3J3YXJkZWQgdG8gSEEgdXNpbmcgbm9ybWFsIElQ
IGhvcC1ieS1ob3Agcm91dGluZy4gV2hlbiBIQSBnZXRzIHRoZSByZWdpc3RyYXRpb24gcmVxdWVz
dCBtZXNzYWdlIGFuZCBsZWFybnMgdGhlIENvQSwgaXQgc2VhcmNoZXMgaXRzIGxhYmVsIHRhYmxl
IHRvIGZpbmQgdGhlIHRhYmxlIHdpdGggdGhlIE1OIGhvbWUgYWRkcmVzcyBhcyBGb3J3YXJkaW5n
IEVxdWl2YWxlbmNlIENsYXNzIChGRUMpLiBUaGVuLCBpdCB3aWxsIHNlbmQgYSBsYWJlbCByZXF1
ZXN0IHVzaW5nIENSLUxEUCB0byBGQSB3aXRoIHRoZSBDb0EgYXMgRkVDLiBGQSByZXBsaWVzIHdp
dGggYW4gTERQIGxhYmVsIG1hcHBpbmcgbWVzc2FnZSB0byBIQS4gV2hlbiB0aGlzIGxhYmVsIG1h
cHBpbmcgbWVzc2FnZSBhcnJpdmVzIGF0IEhBLCB0aGUgTFNQIHdvdWxkIGhhdmUgYmVlbiBlc3Rh
Ymxpc2hlZC4NDUFmdGVyIHRoYXQsIEhBIGNoYW5nZXMgaXRzIGxhYmVsIHRhYmxlIHRoYXQgdXNl
cyB0aGUgTU4gaG9tZSBhZGRyZXNzIGFzIEZFQy4gSXQgc2V0cyB0aGUgb3V0Z29pbmcgcG9ydCBl
bnRyaWVzIG9mIHRoZSBMU1AgZnJvbSBIQSB0byBGQS4gSW4gdGhpcyB3YXksIEhBIGNhbiByZWxh
eSB0aGUgcGFja2V0cyBkZXN0aW5lZCB0byBNTiBob21lIGFkZHJlc3MgdG8gaXRzIGN1cnJlbnQg
bG9jYXRpb24gaW4gdGhlIGZvcmVpZ24gbmV0d29yay4gRmluYWxseSwgSEEgc2VuZHMgYSByZWdp
c3RyYXRpb24gcmVwbHkgdG8gRkEgYWxvbmcgdGhlIExTUCBmcm9tIEhBIHRvIEZBLiBXaGVuIEZB
IHJlY2VpdmVzIHRoZSByZWdpc3RyYXRpb24gcmVwbHksIGl0IHJlY29yZHMgdGhlIGluY29taW5n
IHBvcnQgbnVtYmVyIGFuZCBpbiBsYWJlbCB2YWx1ZSBvZiB0aGUgcmVwbHkgbWVzc2FnZS4NDVBh
Y2tldHMgZnJvbSBhIG5vZGUgdG8gdGhlIE1OIGFyZSBhZGRyZXNzZWQgdG8gdGhlIE1OIGhvbWUg
YWRkcmVzcy4gSWYgdGhlIE1OIGlzIGxvY2F0ZWQgaW4gYSBmb3JlaWduIG5ldHdvcmssIHBhY2tl
dHMgYXJlIGludGVyY2VwdGVkIGJ5IHRoZSBIQS4gSEEgdXNlcyB0aGUgaW5jb21pbmcgbGFiZWwg
dmFsdWUgYXMgYW4gaW5kZXggdG8gbG9vayB1cCBpdHMgbGFiZWwgdGFibGUuIEhBIGluc2VydHMg
dGhlIGxhYmVsIHZhbHVlIGluIHRoZSBsYWJlbCB0YWJsZSBpbnRvIHBhY2tldCBhbmQgc2VuZHMg
aXQgb3V0IHRocm91Z2ggdGhlIHBvcnQgaW5kaWNhdGVkIGluIHRoZSB0YWJsZS4gSWYgTU4gaXMg
c3RpbGwgaW4gdGhlIGhvbWUgbmV0d29yaywgdGhlbiBvdXRnb2luZyBwb3J0IGVudHJpZXMgYXJl
IGVtcHR5LiBUaGUgcGFja2V0IHdpbGwgYmUgc2VudCB0byB0aGUgSVAgbGF5ZXIgYW5kIHNlbnQg
b3V0IGZyb20gdGhlIHBvcnQgaW5kaWNhdGVkIGluIHRoZSBjb3JyZXNwb25kaW5nIHJvdXRpbmcg
dGFibGUgZW50cnkuIFRoZSBmaXJzdCBwYWNrZXQgaXMgZGVsaXZlcmVkIGZyb20gSEEgdG8gRkEg
YWxvbmcgdGhlIExTUCAoTEVSMS1MU1IxLUxTUjItTEVSMikgYnkgbGFiZWwgc3dhcHBpbmcuIEZB
IHJlY2VpdmVzIHRoZSBmaXJzdCBwYWNrZXQgYW5kIGxvb2tzIHVwIGl0cyBsYWJlbCB0YWJsZS4g
U2luY2UgaXQgaXMgdGhlIGVncmVzcyBvZiB0aGUgTFNQIGZyb20gSEEgdG8gRkEgYW5kIHRoZSBv
dXRnb2luZyBwb3J0IGVudHJpZXMgYXJlIGVtcHR5LCBGQSBzdHJpcHMgb2ZmIHRoZSBsYWJlbCBh
bmQgc2VuZHMgdGhlIHBhY2tldHMgdG8gdGhlIElQIGxheWVyLiBGaW5hbGx5LCBGQSBmb3J3YXJk
cyB0aGUgcGFja2V0IHRvIE1OIGJhc2VkIG9uIHRoZSBuZXdseS1hZGRlZCBob3N0IHNwZWNpZmlj
IHJvdXRpbmcgdGFibGUuIE1OIHJlY2VpdmVzIHRoZSBwYWNrZXQgc2VudCBieSBhIG9yaWdpbmF0
aW5nIG5vZGUuIERpcmVjdGx5IGFmdGVyIGRlbGl2ZXJpbmcgdGhlIGZpcnN0IHBhY2tldCwgSEEg
dHJhbnNtaXRzIHRoZSBDb0Egb2YgTU4gdG8gdGhlIGluZ3Jlc3MgTEVSLiBBZnRlciB0aGUgTEVS
IG9mIEZOIHJlY2VpdmVzIHRoZSBDb0Egb2YgTU4gZm9ybSBIQSwgdGhlIG5ldyBMU1AgKExFUjMt
TFNSMS1MU1IyLUxFUjIpIGJldHdlZW4gdGhlIExFUiBhbmQgRkEgaXMgZXN0YWJsaXNoZWQuIEZy
b20gdGhlIG5leHQgcGFja2V0LCB0aGUgTEVSIGlzIGRpcmVjdGx5IGRlbGl2ZXJlZCB0byBGQSB1
c2luZyB0aGUgbmV3bHktZXN0YWJsaXNoZWQgTFNQIHR1bm5lbCB3aGljaCBpcyByZWR1Y2VkIHRo
ZSBkaXN0YW5jZSBvZiBGTiBhbmQgTU4uDQ1XaGVuIE1OIG1vdmVzIGZyb20gb25lIEZBIHRvIGFu
b3RoZXIsIHRoZSByZWdpc3RyYXRpb24gcHJvY2VkdXJlIGlzIHJlcGVhdGVkIG9uY2UgYmV0d2Vl
biB0aGUgSEEgYW5kIG5ldyBGQS4gVGhlIGV4aXN0aW5nIExTUCBzaG91bGQgYmUgY2hhbmdlZCB0
byB0aGUgbmV3IEZBLiBUaGUgZm9sbG93aW5nIGlzc3VlcyBhcmUgZnVydGhlciBjb25zaWRlcmVk
IG9uIHRoZSBNUExTIG5ldHdvcmsuDQ0tIFBhdGggcmVyb3V0aW5nDS0gUGF0aCBleHRlbnNpb24N
LSBMYWJlbCBiaW5kaW5nIGZvciB0aGUgTFNQIGZyb20gRk4gdG8gbmV3IEZBDQ0NICAgICAgICAg
ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0gICAgfCAgICAgIFRoZSBNUExT
IE5ldHdvcmsgICAgICAgIHwgICAgICstLS0tLS0tLS0tKw0gICAgICAgICAgICAgIHwgICAgd2l0
aCBNb2JpbGl0eSBTdXBwb3J0ICAgICB8ICAgICB8IEZvcmVpZ24gIHwNICAgICAgICAgICAgICB8
ICAgICAgKy0tLS0rICAgICAgICAgICAgICAgICAgfCAgICAgfCBNb2JpbGUgSVB8DSAgICAgICAg
ICAgICAgfCAgICAgIHwgSEEgfCAgICAgICAgICAgICAgICArLSstLSsgIHwgTmV0d29yayAgfA0g
ICAgICAgICAgICAgIHwgICAgICArLSstLSsgICAgICAgICAgICAgICAgfCBGQTF8ICB8ICstLS0t
LS0rIHwNKy0tLS0tLS0tLSsgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgL3xMRVIyKy0t
Ky18b2xkIE1OfCB8DXxIb21lICAgICB8IHwtKy0tKyAgKy0tKy0tLSsgICstLS0tLS0rICAgLyAr
LS0rLSsgIHwgKy0tLS0tLSsgfA18TW9iaWxlIElQKy0rTEVSMSstLSsgTFNSMSArLS0rIExTUjIg
Ky0tKyAgICAgfCAgICArLS0tLS0tLS0tLSsNfE5ldHdvcmsgIHwgfC0tLS0rICArLS0rLS0tKyAg
Ky0tLS0tLSsgICBcICAgIHwgICAgIA0rLS0tLS0tLS0tKyAgIHwgIFwgICAgIHwgICAgICAgICAg
ICAgICAgICBcICAgfCAgICArLS0tLS0tLS0tLSsNICAgICAgICAgICAgICB8ICAgXCAgICB8ICAg
ICAgICAgICAgICAgICAgIFwgIHwgICAgfCBGb3JlaWduICB8DSAgICAgICAgICAgICAgfCAgICBc
ICAgfCAgICAgICAgICAgICAgICAgICAgXCB8ICAgIHwgTW9iaWxlIElQfA0gICAgICAgICAgICAg
IHwgICAgIFwgIHwgICAgICAgICAgICAgICAgICAgKy0rKy0rICB8IE5ldHdvcmsgIHwNICAgICAg
ICAgICAgICB8ICAgICstKy0rLS0rICAgICAgICAgICAgICAgIHwgRkEyfCAgfCArLS0tLS0tKyB8
DSAgICAgICAgICAgICAgKy0tLS0rIExFUjMgKy0tLS0tLS0tLS0tLS0tLS0rTEVSNCstLSstfE5l
dyBNTnwgfA0gCSAgICAgICAgICAgKy0tLSstLSsgICAgICAgICAgICAgICAgKy0tLS0rICB8ICst
LS0tLS0rIHwNICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgKy0tLS0tLS0tLS0rDSAgICAgICAgICAgICAgICAgICAgICstKy0tKw0gICAgICAgICAgICAg
ICAgICAgICB8IEZOIHwNICAgICAgICAgICAgICAgICAgICAgKy0tLS0rDQ1GaWd1cmUgMi4gVGhl
IE1QTFMgTmV0d29yayBBcmNoaXRlY3R1cmUgd2l0aCBNb2JpbGl0eSBTdXBwb3J0IA0oU2NlbmFy
aW8gMiA6IFF1ZXJ5IEJlZm9yZSBUdW5uZWxpbmcpDQ0NRmlndXJlIDIgc2hvd3MgdGhlIE1QTFMg
bmV0d29yayBhcmNoaXRlY3R1cmUgdXNpbmcgU2NlbmFyaW8gMiAoUXVlcnkgQmVmb3JlIFR1bm5l
bGluZykuIEluIHRoaXMgc2NlbmFyaW8sIHRoZSBIQSBpcyBhdHRhY2hlZCBhdCB0aGUgTFNSIGFu
ZCBpcyBub3QgY2FwYWJsZSB0byBpbnRlcmNlcHQgSVAgcGFja2V0cy4gQnV0LCB0aGUgcmVnaXN0
cmF0aW9uIHByb2NlZHVyZSBpcyB0aGUgc2FtZSB3aXRoIFNjZW5hcmlvIDEuIEFjY29yZGluZyB0
byBnZW9ncmFwaGljYWwgYXJlYSBhbmQgcm91dGluZyBwYXRoLCBIQSBtYXkgY292ZXIgbW9yZSB0
aGFuIG9uZSByZWdpb25hbCBNb2JpbGUgSVAgbmV0d29ya3MuIA0NVGhlIHR1bm5lbGluZyBwcm9j
ZWR1cmUgb2YgdGhpcyBtb2RlbCBtaWdodCBiZSBkaWZmZXJlbnQgZnJvbSB0aGF0IG9mIFNjZW5h
cmlvIDEuIFdoZW4gYSBGTiBhdCBMRVIzIHNlbmRzIHBhY2tldHMgdG8gYSBNTiBsb2NhdGVkIGlu
IHRoZSBmb3JlaWduIGFyZWEsIHRoZSBpbmdyZXNzIExFUiAoTEVSMykgaGFzIHRvIGRlY2lkZSB0
aGUgcmVsZXZhbnQgZm9yd2FyZGluZyBwYXRoIGRlcGVuZGluZyBvbiByb3V0aW5nIGluZm9ybWF0
aW9uLiBUaGVyZSBhcmUgdGhyZWUgYWx0ZXJuYXRpdmVzIHRvIGZvcndhcmQgSVAgcGFja2V0cy4N
DWNhc2UgKGEpIGhvbWUgSVAgYWRkcmVzcyBvZiBhIE1OIGFzIGRlZmF1bHQgZm9yd2FyZGluZyBw
YXRoDWNhc2UgKGIpIEhBIGFkZHJlc3Mgb2YgdGhlIE1ODWNhc2UgKGMpIENvQSBhZGRyZXNzIG9m
IHRoZSBNTiwgdGhhdCBpcywgZWdyZXNzIExFUi9GQSBhcyB0dW5uZWxpbmcgcmVjZWl2ZSBlbmRw
b2ludCBvZiBNTg0NRm9yIHRoZSBjYXNlIChhKSwgdGhlIGFkZGl0aW9uYWwgcHJvY2Vzc2luZyBv
biB0aGUgaG9tZSBMRVIgaXMgcmVxdWlyZWQgc2luY2UgdGhlIFVEUCB0cmFmZmljIHRyaWVzIHRv
IHRha2UgdGhlIGRlZmF1bHQgcGF0aCB3aXRob3V0IHJlc2VydmF0aW9uIG9mIGxhYmVsIGZsb3cu
IEluIGNhc2UgKGIpLCB0aGUgSEEgYWRkcmVzcyBzaG91bGQgYmUgYWxyZWFkeSBrbm93biBieSBh
bGwgbmV0d29yayBlbGVtZW50cyBhbmQgdGhlcmUgaXMgbm8gYWR2YW50YWdlIHRvIGxvY2F0ZSBh
dCB0aGUgTFNSLiBJdCByZXF1aXJlcyBmb3IgZnVydGhlciBzdHVkeS4NDUl0IGlzIHByZWZlcmFi
bGUgb2YgY2FzZSAoYykgdGhhdCB0aGUgZm9yd2FyZGluZyBwYXRoIGZyb20gaW5ncmVzcyBMRVIg
c2hvdWxkIGJlIGN1dCB0aHJvdWdoIHRoZSBlZ3Jlc3MgTEVSL0ZBLCB0aGUgQ29BIG9mIHRoZSBN
Ti4gRm9yIGFsbCB0aGUgY2FzZXMsIHRoZSBpbmdyZXNzIExFUiBzaG91bGQgZmluZCBmb3J3YXJk
aW5nIHBhdGggd2l0aCByZWxldmFudCBxdWVyeSBwcm9jZXNzLiBUaGUgcXVlcnkgcHJvY2VzcyBp
cyBkZXBlbmRpbmcgb24gd2hldGhlciB0aGUgZGVzdGluYXRpb24gaXMgYSBtb2JpbGUgdXNlciBv
ciBub3QuIEl0IG1heSBjYXVzZSB0aGF0IHRoaXMgc2NlbmFyaW8gaXMgbm90IGFwcGxpY2FibGUg
dG8gSVB2NCBuZXR3b3JrIHdpdGhvdXQgcmVsZXZhbnQgcHJvY2VkdXJlIHNpbmNlIHRoZSBJUHY0
IGFkZHJlc3Mgc3RydWN0dXJlIGlzIG5vdCBjYXBhYmxlIG9mIGlkZW50aWZ5aW5nIG1vYmlsZSB0
ZXJtaW5hbC4gRm9yIElQdjYsIGl0IHNlZW1zIHRvIGJlIGFwcGxpY2FibGUgd2hlbiBzb21lIGFk
ZHJlc3Mgc3BhY2VzIGFyZSBkZWRpY2F0ZWQgZm9yIG1vYmlsZS4gT25lIHBvc3NpYmxlIGFwcGxp
Y2F0aW9uIGZvciB0aGlzIHNjZW5hcmlvIG1heSBiZSB0aGUgTVBMUy1iYXNlZCBJTVQtMjAwMCBO
ZXR3b3JrIHVzaW5nIElwdjYuDQ1Gb3IgdGhpcyBzY2VuYXJpbywgaXQgcmVxdWlyZXMgdGhlIHF1
ZXJ5IHByb2Nlc3MgdG8gZmluZCB0aGUgZGVzdGluYXRpb24gdHVubmVsIGVuZHBvaW50cyBvbiB0
aGUgTVBMUyBuZXR3b3JrLiBUaGUgTEVSIGRlY2lkZXMgd2hldGhlciBkZXN0aW5hdGlvbnMgYXJl
IGZvciBtb2JpbGUgYXBwbGljYXRpb24uIEFuZCBpdCB0cmllcyB0byBsb29rIHVwIHRoZWlyIGxh
YmVsIHRhYmxlIGZvciBpbmNvbWluZyBwYWNrZXRzLiBXaGVuIHRoZSByZWxldmFudCBwb3J0IGVu
dHJpZXMgYW5kIGxhYmVscyBhcmUgZm91bmQsIGl0IHNlbmRzIHRoZW0gdG8gdGhlIG91dHB1dCBw
b3J0IHdpdGggYSBsYWJlbCBoZWFkZXIuIElmIG5vIGVudHJ5IGlzIHJldHVybmVkLCBpdCBzZW5k
cyB0aGUgcXVlcnkgbWVzc2FnZXMgdG8gdGhlIEhBIGRlYWxpbmcgd2l0aCBkZXN0aW5hdGlvbiBJ
UCBhZGRyZXNzLiBGb3IgdGhlIFVEUCB0cmFmZmljLCBpdCBhbHNvIHJlcXVpcmVzIHRoZSBxdWVy
eSBwcm9jZXNzIG9uIGRlc3RpbmF0aW9uIGFkZHJlc3MgdG8gYXNzaWduIHRoZSBkZWZhdWx0IGxh
YmVsIHZhbHVlLiBUaGVuLCB0aGUgaW5jb21pbmcgSVAgcGFja2V0cyBtYXkgd2FpdCBmb3Igc2V2
ZXJhbCBzZWNvbmRzIHRvIGdldCB0aGUgYWRkcmVzcyBvZiBlZ3Jlc3MgTEVSL0ZBLiANDUZvciB0
aGUgbWF0dGVycyBvZiBRb1MgYW5kIHRyYWZmaWMgY29udHJvbCwgaXQgc2hvdWxkIGludmVzdGln
YXRlIHdoZXRoZXIgdGhlIGJhbmR3aWR0aHMgYmV0d2VlbiBpbmdyZXNzIExFUiBhbmQgZWdyZXNz
IExFUiBhcmUgYXZhaWxhYmxlIG9yIG5vdC4gV2l0aCB0aGVzZSBjb25jZXJucywgdGhlIENSLUxE
UCBvciBSU1ZQLVRFIG1heSBiZSB1c2VmdWwgdG8gdGFrZSBhIHJlbGV2YW50IGZvcndhcmRpbmcg
cGF0aC4NDVRoZSBkZXRhaWwgZGlzY3Vzc2lvbnMgb24gUXVlcnkgQmVmb3JlIFR1bm5lbGluZyBz
Y2VuYXJpbyByZXF1aXJlIGZvciBmdXJ0aGVyIHN0dWR5Lg0NDTIuMy4gUm91dGluZyBDb25zaWRl
cmF0aW9ucw0NVGhlIHJvdXRpbmcgb24gdGhlIE1QTFMgbmV0d29yayBpcyBkZXBlbmRpbmcgb24g
bG9jYXRpb25zIG9mIEhBIGFuZCBGQS4gSW4gTVBMUyBuZXR3b3JrLCB0aHJvdWdoIGZsb3cgY2xh
c3NpZmljYXRpb24sIGVhY2ggZmxvdyBtYXkgYmUgZGlmZmVyZW50IGluIGdyYWRlcyBvZiBzZXJ2
aWNlLiBBbiBMU1Agc2hvdWxkIG1lZXQgY2VydGFpbiBRb1MgcmVxdWlyZW1lbnRzIG9mIGRpZmZl
cmVudGlhbCBmbG93cyB1c2luZyBDUi1MRFAgb3IgUlNWUC1URS4NDVRoZSBkZXRhaWwgZGlzY3Vz
c2lvbnMgb24gcm91dGluZyBpc3N1ZXMgb2YgdGhlIE1QTFMgbmV0d29yayB3aXRoIG1vYmlsaXR5
IHN1cHBvcnQgYXJlIGZ1cnRoZXIgc3R1ZHkuDQ0NMi40LiBJbnRlcndvcmtpbmcgb2YgZXhpc3Rp
bmcgTW9iaWxlIElQIG5ldHdvcmsNDUl0IHJlcXVpcmVzIGZvciBmdXJ0aGVyIHN0dWR5Lg0NDQ0N
DQ0NDTMuIERlc2NyaXB0aW9uIG9mIHRoZSBQcm90b2NvbA0NMy4xLiBHZW5lcmFsIEFzc3VtcHRp
b25zDQ1JbiB0aGlzIGRyYWZ0LCB0aGUgbWFpbiBpc3N1ZXMgb2YgTVBMUyBuZXR3b3JrIGFyY2hp
dGVjdHVyZSB3aXRoIG1vYmlsaXR5IHN1cHBvcnQgYXJlIGZvY3VzZWQgb24gdGhlIGNvbnRyb2wg
cHJvY2VkdXJlIHN1Y2ggYXMgcmVnaXN0cmF0aW9uLCBhZ2VudCBkaXNjb3ZlcnksIExTUCBlc3Rh
Ymxpc2htZW50IGFuZCBMU1AgRXh0ZW5zaW9uLCBldGMuIEFnZW50IGFkdmVydGlzZW1lbnQgYW5k
IGRpc2NvdmVyeSB3aXRoaW4gdGhlIHNjb3BlIG9mIHJlZ2lvbmFsIG1vYmlsZSBJUCBuZXR3b3Jr
IGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuIFdlIGFzc3VtZSB0aGF0IHRo
ZSBGQXMgc3VwcG9ydCBzZWN1cml0eSBhc3NvY2lhdGlvbnMgDQ1XZSBhbHNvIGFzc3VtZSBvbiB0
aGUgbW9iaWxlIHdpcmVsZXNzIElQIG5ldHdvcmtzIHRoYXQgYXJlIGRpdmlkZWQgaW50byBhIG51
bWJlciBvZiBjZWxsIHJlZ2lvbnMgYWNjb3JkaW5nIHRvIGdlb2dyYXBoaWNhbCBhcmVhLiBFYWNo
IGNlbGwgaXMgY292ZXJlZCBieSBhIEJhc2UgU3RhdGlvbiAoQlMpIHdoaWNoIHByb3ZpZGVzIHdp
cmVsZXNzIElQIGFjY2VzcyB0byB0aGUgTU4uIFRoZSBCUyBpcyBjb25uZWN0ZWQgdG8gdGhlIExF
UiB0byBzdXBwb3J0IG1vYmlsaXR5Lg0NDTMuMi4gTFNQIFR1bm5lbHMgZm9yIE1vYmlsaXR5IFN1
cHBvcnQNDVRoZXJlIHJlcXVpcmVzIHR3byB0eXBlcyBvZiBMU1AgdHVubmVscyBpbiB0aGUgTUxQ
UyBuZXR3b3JrIHdpdGggbW9iaWxpdHkgc3VwcG9ydDsNDS0gTFNQIHR1bm5lbHMgYmV0d2VlbiB0
aGUgaW5ncmVzcyBMRVIgYW5kIEhBDS0gTFNQIHR1bm5lbHMgYmV0d2VlbiBIQSBhbmQgZWdyZXNz
IExFUi9GQQ0tIERpcmVjdCBMU1AgdHVubmVscyBiZXR3ZWVuIGluZ3Jlc3MgTEVSIGFuZCBlZ3Jl
c3MgTEVSL0ZBIChzY2VuYXJpbyAyKQ0NVGhlIGV4aXN0aW5nIExEUCBzcGVjaWZpY2F0aW9uIGlz
IHdlbGwgZGVzY3JpYmVkIHRvIGVzdGFibGlzaCBMU1AgdHVubmVscyBmb3IgbW9iaWxpdHkuIFRo
ZSBhZGRyZXNzIG9mIEhBIGFuZCBGQSBmb3IgTFNQIHR1bm5lbHMgd2lsbCBiZSBnaXZlbiBieSB0
aGUgQWdlbnQgRGlzY292ZXJ5IFByb2NlZHVyZSB3aXRoaW4gdGhlIE1QTFMgbmV0d29yay4NDVRo
ZSBMU1Agd2l0aCBRb1MgY29uc3RyYWludHMgd2lsbCBiZSBjb250YWluZWQgaW4gdGhlIENSLUxE
UCBvciBSU1ZQLVRFIHNwZWNpZmljYXRpb24gWzldLFsxMF0uDQ0NMy4zLiBSZWdpc3RyYXRpb24g
b2YgTW9iaWxlIE5vZGUNDU1OIGRldGVybWluZXMgd2hldGhlciBpdCBpcyBhdCBob21lIG9yIGlu
IGEgZm9yZWlnbiBuZXR3b3JrIHdoZW4gaXQgcmVjZWl2ZXMgYWdlbnQgYWR2ZXJ0aXNlbWVudCBt
ZXNzYWdlcyBicm9hZGNhc3QgYnkgdGhlIG1vYmlsaXR5IGFnZW50cy4gSWYgdGhlIE1OIGRldGVy
bWluZXMgdGhhdCBpdCBpcyBpbiBhIGZvcmVpZ24gbmV0d29yaywgdGhlIE1OIGFjcXVpcmVzIGEg
dGVtcG9yYXJ5IENvQSBmcm9tIEZBIGFuZCBzZW5kcyBhIHJlZ2lzdHJhdGlvbiByZXF1ZXN0IHRv
IEZBLiBTaW5jZSBGQSBpcyBhbiBMRVIsIGl0IHdpbGwgYW5hbHl6ZSB0aGUgaW5jb21pbmcgcmVn
aXN0cmF0aW9uIHJlcXVlc3QgbWVzc2FnZSBhbmQgZ2V0IHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNz
IG9mIHRoZSBIQS4gVGhlbiBGQSB1cGRhdGVzIGl0cyByb3V0aW5nIHRhYmxlIGFuZCBhZGRzIGEg
aG9zdCBzcGVjaWZpYyByb3cgd2l0aCB0aGUgbGFiZWwgdmFsdWUgb2YgTU4gaG9tZSBhZGRyZXNz
LiBJbiBhZGRpdGlvbiwgaXQgc2V0cyB0aGUgb3V0Z29pbmcgcG9ydCB2YWx1ZSBvZiB0aGlzIGVu
dHJ5IHRvIGJlIHRoZSBpbmNvbWluZyBwb3J0IG51bWJlciBmcm9tIHdoaWNoIGl0IHJlY2VpdmVk
IHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdC4NDU1OICAgICAgICAgICAgICAgICAgICAgICAgRkEx
KExFUjIpICAgICAgICAgICAgICAgICAgICAgICAgICAgSEENfCAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA18LS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DXwgQnJv
YWRjYXN0IEFnZW50ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHwNfCBTb2xpY2l0YXRpb24gTWVzc2FnZShJQ01QKSAgfCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgfA18PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB8DXwgQnJvYWRjYXN0IEFnZW50ICAgICAgICAgICAgIHwgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHwNfCBBZHZlcnRpc2VtZW50IE1lc3NhZ2UoSUNNUCkg
fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA18ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DXwtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tPnwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNfCBNTiBS
ZWdpc3RyYXRpb24gUmVxdWVzdChVRFApfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+
fA18ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IE1OIFJlZ2lzdHJhdGlvbiBSZXF1ZXN0
IChVRFApICB8DXwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHwNfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfA18PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18
IE1OIFJlZ2lzdHJhdGlvbiBSZXBseSAoVURQKSAgICB8DXwgTU4gUmVnaXN0cmF0aW9uIFJlcGx5
IChVRFApIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNfCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA18ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8ICAgIChubyBlbnRyeSBiZXR3ZWVuIEhBIGFuZCBGQSl8
DXwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLXwNfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBMYWJlbCBSZXF1ZXN0IE1l
c3NhZ2UoQ1ItTERQKSAgfA18ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8DXwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwNfCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfCBMYWJlbCBtYXBwaW5nIE1lc3NhZ2UoQ1ItTERQKSAgfA18ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQ1GaWd1cmUg
My4gUmVnaXN0cmF0aW9uIG9mIE1vYmlsZSBOb2RlIGF0IHRoZSBNUExTIE5ldHdvcmsNDUJhc2Vk
IG9uIHRoZSBJUCByb3V0aW5nIHRhYmxlLCBGQSBmb3J3YXJkcyB0aGUgcmVnaXN0cmF0aW9uIHJl
cXVlc3QgbWVzc2FnZSB0b3dhcmQgSEEuIFRoZSByZXF1ZXN0IG1lc3NhZ2UgaXMgZm9yd2FyZGVk
IHRvIEhBIGluIGEgaG9wLWJ5LWhvcCBtYW5uZXIgdXNpbmcgbm9ybWFsIElQIHJvdXRpbmcuIFdo
ZW4gSEEgZ2V0cyB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QgbWVzc2FnZSBhbmQgbGVhcm5zIHRo
ZSBDb0EsIGl0IHNlYXJjaGVzIGl0cyBsYWJlbCB0YWJsZSB0byBmaW5kIHRoZSByb3cgd2l0aCB0
aGUgTU4gaG9tZSBhZGRyZXNzIGFzIEZvcndhcmRpbmcgRXF1aXZhbGVuY2UgQ2xhc3MgKEZFQyku
IFRoZW4sIGl0IHdpbGwgc2VuZCBhIGxhYmVsIHJlcXVlc3QgdXNpbmcgQ1ItTERQIHRvIEZBIHdp
dGggdGhlIENvQSBhcyBGRUMuIEZBIHJlcGxpZXMgd2l0aCBhbiBMRFAgbGFiZWwgbWFwcGluZyBt
ZXNzYWdlIHRvIEhBLiBXaGVuIHRoaXMgbGFiZWwgbWFwcGluZyBtZXNzYWdlIGFycml2ZXMgYXQg
SEEsIHRoZSBMU1Agd291bGQgaGF2ZSBiZWVuIGVzdGFibGlzaGVkLiANDUFmdGVyIHRoYXQsIEhB
IGNoYW5nZXMgdGhlIHJvdyBpbiBpdHMgbGFiZWwgdGFibGUgdGhhdCB1c2VzIHRoZSBNTiBob21l
IGFkZHJlc3MgYXMgRkVDLiBJdCBzZXRzIHRoZSBlbXB0eSBvdXQgbGFiZWwgYW5kIG91dGdvaW5n
IHBvcnQgZW50cmllcyB0byB0aGUgdmFsdWVzIG9mIG91dCBsYWJlbCBhbmQgb3V0Z29pbmcgcG9y
dCBvZiB0aGUgTFNQIGZyb20gSEEgdG8gRkEuIEluIHRoaXMgd2F5LCBIQSBjYW4gcmVsYXkgdGhl
IHBhY2tldHMgZGVzdGluZWQgdG8gTU4gaG9tZSBhZGRyZXNzIHRvIGl0cyBjdXJyZW50IGxvY2F0
aW9uIGluIHRoZSBmb3JlaWduIG5ldHdvcmsuIEZpbmFsbHksIEhBIHNlbmRzIGEgcmVnaXN0cmF0
aW9uIHJlcGx5IHRvIEZBIGFsb25nIHRoZSBMU1AgZnJvbSBIQSB0byBGQS4gV2hlbiBGQSByZWNl
aXZlcyB0aGUgcmVnaXN0cmF0aW9uIHJlcGx5LCBpdCByZWNvcmRzIHRoZSBpbmNvbWluZyBwb3J0
IG51bWJlciBhbmQgaW4gbGFiZWwgdmFsdWUgb2YgdGhlIHJlcGx5IG1lc3NhZ2UuIFRoZW4gaXQg
YWRkcyBhIG5ldyByb3cgaW4gaXRzIGxhYmVsIHRhYmxlLg0NDTMuNC4gQWdlbnQgQWR2ZXJ0aXNl
bWVudCBhbmQgU29saWNpdGF0aW9uDQ1Nb2JpbGUgYWdlbnRzIChpLmUuLCBmb3JlaWduIGFnZW50
cyBhbmQgaG9tZSBhZ2VudHMpIGFkdmVydGlzZSB0aGVpciBwcmVzZW5jZSB2aWEgQWdlbnQgQWR2
ZXJ0aXNlbWVudCBtZXNzYWdlcy4gQSBtb2JpbGUgbm9kZSBtYXkgb3B0aW9uYWxseSBzb2xpY2l0
IGFuIEFnZW50IEFkdmVydGlzZW1lbnQgbWVzc2FnZSBmcm9tIGFueSBsb2NhbGx5IGF0dGFjaGVk
IG1vYmlsaXR5IGFnZW50cyB0aHJvdWdoIGFuIEFnZW50IFNvbGljaXRhdGlvbiBtZXNzYWdlLiBB
IG1vYmlsZSBub2RlIHJlY2VpdmVzIHRoZXNlIEFnZW50IEFkdmVydGlzZW1lbnRzIGFuZCBkZXRl
cm1pbmVzIHdoZXRoZXIgaXQgaXMgb24gaXRzIGhvbWUgbmV0d29yayBvciBhIGZvcmVpZ24gbmV0
d29yay4NDSAgICAgICAgICBGQStIQSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTU4N
ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DSAgICAgICAg
ICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0gICAgICAgICAgIHwgQWdl
bnQgQWR2ZXJ0aXNlbWVudCBNZXNzYWdlICAgICAgIHwNICAgICAgICAgICB8ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8DSAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tfA0gICAgICAgICAgIHwgQWdlbnQgU29saWNpdGF0aW9uIE1lc3NhZ2Ug
ICAgICAgIHwNICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8
DQ1GaWd1cmUgNC4gQWdlbnQgRGlzY292ZXJ5IG9mIE1vYmlsZSBOb2RlIGF0IHRoZSBNUExTIE5l
dHdvcmsNDUlmIHNlbnQgcGVyaW9kaWNhbGx5LCB0aGUgbm9taW5hbCBpbnRlcnZhbCBhdCB3aGlj
aCBBZ2VudCBBZHZlcnRpc2VtZW50cyBhcmUgc2VudCBTSE9VTEQgYmUgMS8zIG9mIHRoZSBhZHZl
cnRpc2VtZW50IExpZmV0aW1lIGdpdmVuIGluIHRoZSBNUExTIHNoaW0gaGVhZGVyLiBUaGlzIGFs
bG93cyBhIG1vYmlsZSBub2RlIHRvIG1pc3MgdGhyZWUgc3VjY2Vzc2l2ZSBhZHZlcnRpc2VtZW50
cyBiZWZvcmUgZGVsZXRpbmcgdGhlIGFnZW50IGZyb20gaXRzIGxpc3Qgb2YgdmFsaWQgYWdlbnRz
LiBUaGUgYWN0dWFsIHRyYW5zbWlzc2lvbiB0aW1lIGZvciBlYWNoIGFkdmVydGlzZW1lbnQgU0hP
VUxEIGJlIHNsaWdodGx5IHJhbmRvbWl6ZWQgWzExXSBpbiBvcmRlciB0byBhdm9pZCBzeW5jaHJv
bml6YXRpb24gYW5kIHN1YnNlcXVlbnQgY29sbGlzaW9ucyB3aXRoIG90aGVyIEFnZW50IEFkdmVy
dGlzZW1lbnRzIHRoYXQgbWF5IGJlIHNlbnQgYnkgb3RoZXIgYWdlbnRzLiANDQ0zLjUuIExvY2F0
aW9uIFF1ZXJ5IG9mIE1vYmlsZSBOb2RlDQ1UaGlzIHByb2NlZHVyZSBtYXkgYmUgT1BUSU9OQUxM
WSB1c2VkIGZvciBTY2VuYXJpbyAyIChRdWVyeSBCZWZvcmUgVHVubmVsaW5nKSB0byBmaW5kIHRo
ZSBkaXJlY3Qgc2hvcnQtY3V0IHBhdGggb2YgZWdyZXNzIExFUiBvciB0aGUgZGVmYXVsdCBmb3J3
YXJkaW5nIHBhdGggb2YgVURQIHRyYWZmaWMuIFdoZW4gYSBNTiBtb3ZlcyB0byBmb3JlaWduIG1v
YmlsZSBJUCBuZXR3b3JrLCBMRVIzIHF1ZXJpZXMgSEEgZm9yIHRoZSBsb2NhdGlvbiBvZiBNTi4g
SEEgcmVzcG9uc2VzIHRvIExFUjMgd2hldGhlciBpdCBoYXMgdGhlIGluZm9ybWF0aW9uIG9mIGl0
LiANDSAgICAgICAgICAgICBMRVIzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIQQ0g
ICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0gICAgICAg
ICAgICAgfCAgICBMb2NhdGlvbiBRdWVyeSBNZXNzYWdlICAgICAgICAgfA0gICAgICAgICAgICAg
fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0gICAgICAgICAgICAgfDwtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfA0gICAgICAgICAgICAgfCAgICBMb2NhdGlv
biBSZXNwb25zZSBNZXNzYWdlICAgICAgfA0gICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgfA0NRmlndXJlIDUuIExvY2F0aW9uIFF1ZXJ5IG9mIE1vYmlsZSBO
b2RlIGF0IHRoZSBNUExTIE5ldHdvcmsNDVdpdGggUXVlcnkgaW5mb3JtYXRpb24gZnJvbSBIQSwg
TEVSIGluaXRpYXRlcyB0aGUgbGFiZWwgYmluZGluZyBwcm9jZXNzIHRvIHRoZSBlZ3Jlc3MgTEVS
Mi9GQTEgdG8gYSBNTi4gQWZ0ZXIgdGhhdCwgTEVSMyB1cGRhdGVzIHRoZSByb3cgaW4gaXRzIGxh
YmVsIHRhYmxlIHRoYXQgdXNlcyB0aGUgQ29BIG9mIGEgTU4gYXMgRkVDLiBJdCBzZXRzIGEgbGFi
ZWwgdmFsdWUgYW5kIG91dGdvaW5nIHBvcnQgZW50cmllcy4NDUluIGNhc2UgdGhhdCBhIEZOIHNl
bmRzIElQIHBhY2tldHMgdG8gTEVSMyB3aXRob3V0IGFueSByZXF1ZXN0IG1lc3NhZ2UsIExFUjMg
c2VhcmNoZXMgZm9yIGZvcndhcmRpbmcgbGFiZWwgZW50cmllcyB0byB0aGUgZGVzdGluYXRpb24g
TU4uIElmIG5vdCBmb3VuZCwgaXQgc2VuZHMgdGhlIGxvY2F0aW9uIHF1ZXJ5IG1lc3NhZ2VzIHRv
IEhBIHRvIGdldCB0aGUgQ29BIG9mIGEgTU4uIEFmdGVyIHRoYXQsIGl0IGluaXRpYXRlcyB0aGUg
TGFiZWwgcmVxdWVzdCBtZXNzYWdlIHRvIHRoZSBlZ3Jlc3MgTEVSMi9GQTEgZGVzdGluZWQgdG8g
YSBNTi4NDQ1GTiAgICAgICAgICAgTEVSMyAgICAgICAgICAgICAgSEEgICBMU1IgICAgICAgICBG
QTEoTEVSMikgICAgICBNTg18ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICB8ICAg
ICAgICAgICAgICB8ICAgICAgICAgICAgfA18LS0tLS0tLS0tLS0tPnwgICAgICAgICAgICAgICAg
IHwgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgfA18VXNlciBQYWNrZXRzIHwobm8gZW50
cnkpICAgICAgIHwgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgfA18ICAgICAgICAgICAg
IHwtLS0tLS0tLS0tLS0tLS0tPnwgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgfA18ICAg
ICAgICAgICAgIHxMb2NhdGlvbiBRdWVyeSAgIHwgICB8ICAgICAgICAgICAgICB8ICAgICAgICAg
ICAgfA18ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICB8ICAgICAgICAgICAgICB8
ICAgICAgICAgICAgfA18ICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLXwgICB8ICAgICAg
ICAgICAgICB8ICAgICAgICAgICAgfA18ICAgICAgICAgICAgIHxMb2NhdGlvbiBSZXNwb25zZXwg
ICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgfA18ICAgICAgICAgICAgIHwgICAgICAgICAg
ICAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgfA18ICAgICAgICAgICAgIHwt
LS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgICB8ICAgICAgICAgICAgfA18ICAgICAg
ICAgICAgIHwgTGFiZWwgUmVxdWVzdCAgICAgICB8LS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAg
fA18ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8IExhYmVsIFJlcXVlc3R8ICAg
ICAgICAgICAgfA18ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0t
LS0tLS18ICAgICAgICAgICAgfA18ICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS18
IExhYmVsIE1hcHBpbmd8ICAgICAgICAgICAgfA18ICAgICAgICAgICAgIHwgTGFiZWwgTWFwcGlu
ZyAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgfA18ICAgICAgICAgICAgIHwgICAg
ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgfA18ICAgICAgICAg
ICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgICB8ICAgICAgICAgICAgfA18
ICAgICAgICAgICAgIHwgVXNlciBQYWNrZXRzICAgICAgICB8LS0tLS0tLS0tLS0tLT58ICAgICAg
ICAgICAgfA18ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8IFVzZXIgUGFja2V0
cyB8LS0tLS0tLS0tLS0+fA18ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAg
ICAgICAgICAgICB8VXNlciBQYWNrZXRzfA18ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg
ICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgfA0NRmlndXJlIDYuIFVzZXIgRGF0YSBE
ZWxpdmVyeSB1c2luZyBMb2NhdGlvbiBRdWVyeSBhdCB0aGUgTVBMUyBOZXR3b3JrDQ0NMy42LiBM
U1AgRXh0ZW5zaW9uIGZvciBIYW5kb3Zlcg0NVGhlcmUgYXJlIHR3byBwaGFzZXMgaW4gaGFuZG92
ZXIgc2NoZW1lLCB3ZSBjYWxsIGl0IExTUCBFeHRlbnNpb24gYW5kIExTUCBSZWNhbGN1bGF0aW9u
LiBXaGVuIGEgbW9iaWxlIG5vZGUgbW92ZXMgZnJvbSBGb3JlaWduIElQIE5ldHdvcmsgRkExIHRv
IEZBMiwgaXQgc2VuZHMgYSBtZXNzYWdlIHRvIHJlZ2lzdGVyIHRoZSBuZXcgRkEuIFNpZ25hbGlu
ZyBtZXNzYWdlcyBzaG91bGQgYmUgZXhjaGFuZ2VkIGJldHdlZW4gb2xkIEZBIGFuZCBuZXcgRkEg
dG8gZXh0ZW5kIHRoZSBMU1AgdHVubmVsLiBJdCBleHRlbmRzIHRoZSBjdXJyZW50IExTUCBieSBl
c3RhYmxpc2hpbmcgYSBMU1AgYmV0d2VlbiBjdXJyZW50IEZBIGFuZCBuZXcgRkEuIER1cmluZyB0
aGF0IHRpbWUsIG9sZCBGQSBidWZmZXJzIGFsbCB0aGUgcGFja2V0cyBmcm9tIGFuZCB0byB0aGUg
bW9iaWxlIG5vZGUuIE9uY2UgdGhlIExTUCBpcyBlc3RhYmxpc2hlZCwgcGFja2V0cyBhcmUgc2Vu
dCBhbG9uZyB0aGUgbmV3IHBhdGggdG8gdGhlIG1vYmlsZSBub2RlLg1fDSAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIEV4aXN0aW5nICANICAgICAgICstLS0tKyAgICAgICAgICAgICAg
ICAgICAgICAgTFNQICArLS0tLSsgIA0gICAgICAgfCBIQSB8ICAgICstLS0tLS0rICAgKy0tLS0t
LSsgICAgIHwgRkExfCAgICstLS0tLS0tLSsNXyAgICAgIHxMRVIxKy0tLS0rIExTUjEgKy0tLSsg
TFNSMiArLS0tLS0rTEVSMistLS0rIG9sZCBNTiB8DSAgICAgICArLS0rLSsgICAgKy0tLS0tLSsg
ICArLS0tLS0tKyAgICAgKy0tKy0rICAgKy0tLS0tLS0tKw0gICAgICAgICAgIFwgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICB8DSAgICAgICAgICAgIFwgICAgICAgICAg
ICAgICAgICAgICAgRXh0ZW5kZWQgfCAgICAgICAgIHwNICAgICAgICAgICArLSstLS0tKyAgICAg
ICAgICAgICAgICAgICBMU1AgICB8ICAgICAgICAgfA0gICAgICAgICAgIHwgTEVSMyB8ICAgICAg
ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICB8DSAgICAgICAgICAgKy0tKy0tLSsgICAgICAg
ICAgICAgICAgICAgICAgKy0tKy0rICAgICAgIFYNICAgICAgICAgICAgICB8ICAgICAgICAgICAg
ICAgICAgICAgICAgICB8IEZBMnwgICArLS0tLS0tLS0rDSAgICAgICAgICAgICstKy0tKyAgICAg
ICAgICAgICAgICAgICAgICAgfExFUjQrLS0tKyBOZXcgTU4gfA0gICAgICAgICAgICB8IEZOIHwg
ICAgICAgICAgICAgICAgICAgICAgICstLS0tKyAgICstLS0tLS0tLSsNICAgICAgICAgICAgKy0t
LS0rDQ1GaWd1cmUgNy4gTFNQIEV4dGVuc2lvbiBmb3IgTW9iaWxlIElQDQ0NTU4gICAgICAgICAg
ICBOZXcgRkEgICAgICAgICAgICBPbGQgRkEgICAgICAgICAgSEEgICAgIC4uLiAgICBGTg0gfCAg
ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAg
ICB8DSB8LS0tLS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAg
ICAgICAgICAgIHwNIHwgUmVnLiBSZXF1ZXN0ICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tPnwgICAgICAgICAgICAgfA0gfCAgICAgICAgICAgICAgIHwgICAgICAgICBSZWcuIFJlcXVl
c3QgICAgICAgICAgfCAgICAgICAgICAgICB8DSB8ICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgIHwNIHwgICAgICAgICAgICAgICB8ICAg
ICAgICAgIFJlZy4gUmVwbHkgICAgICAgICAgIHwgICAgICAgICAgICAgfA0gfCAgICAgICAgICAg
ICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8DSB8ICAg
ICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tPnwgICAgICAgICAgICAgICB8ICAgICAgICAgICAg
IHwNIHwgICAgICAgICAgICAgICB8TFNQIEV4dGVuc2lvbiArfCAgICAgICAgICAgICAgIHwgICAg
ICAgICAgICAgfA0gfCAgICAgICAgICAgICAgIHwgIExTUCBSZXF1ZXN0ICB8ICAgICAgICAgICAg
ICAgfCAgICAgICAgICAgICB8DSB8ICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLXwgICAg
ICAgICAgICAgICB8ICAgICAgICAgICAgIHwNIHw8LS0tLS0tLS0tLS0tLS18TFNQIEV4dC4gUmVw
bHkrfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfA0gfCBSZWcuIFJlcGx5ICAgIHwgIExT
UCBNYXBwaW5nICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8DSB8ICAgICAgICAgICAg
ICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNIHwtLS0t
LS0tLS0tLS0tLT58ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
fA0gfCBVc2VyIE1lc3NhZ2VzIHwtLS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8DSB8ICAgICAgICAgICAgICAgfCBVc2VyIE1lc3NhZ2VzIHwtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tPnwNIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCBVc2Vy
IE1lc3NhZ2VzICAgICAgICAgICAgICAgfA0gfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg
ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DSANRmlndXJlIDguIE1lc3NhZ2UgU2Vx
dWVuY2UgZm9yIExTUCBFeHRlbnNpb24NDQ1UaGUgTFNQIGV4dGVuc2lvbiBwcm9jZWR1cmVzIGlu
IEZpZ3VyZSA4IGFyZSBhcyBmb2xsb3dzLg0NLSBNTiBtb3ZlcyB0byBhIG5ldyBGQSBhbmQgc2Vu
ZHMgYSBSZWdpc3RyYXRpb24gUmVxdWVzdCBtZXNzYWdlIHRvIE5ldyBGQS4NLSBOZXcgRkEgc2Vu
ZHMgYSBSZWdpc3RyYXRpb24gUmVxdWVzdCBtZXNzYWdlIHRvIEhBLg0tIEhBIHNlbmRzIFJlZ2lz
dHJhdGlvbiBSZXBseSBtZXNzYWdlIGluIHJlc3BvbnNlIHRvIHRoZSBSZWdpc3RyYXRpb24gUmVx
dWVzdC4NLSBJZiBuZXcgRkEgcmVjZWl2ZXMgUmVnaXN0cmF0aW9uIFJlcGx5IG1lc3NhZ2UsIG5l
dyBGQSBzZW5kcyB0aGUgTGFiZWwgUmVxdWVzdCBhbmQgTFNQIEV4dGVuc2lvbiBNZXNzYWdlIHRv
IG9sZCBGQS4NLSBBIExTUCBpcyBlc3RhYmxpc2hlZCBiZXR3ZWVuIG9sZCBGQSBhbmQgbmV3IEZB
IHdoZW4gbmV3IEZBIHJlY2VpdmVzIExhYmVsIE1hcHBpbmcgbWVzc2FnZS4NLSBUaGVuIHRoZSBu
ZXcgRkEgc2VuZHMgUmVnaXN0cmF0aW9uIFJlcGx5IG1lc3NhZ2UgdG8gdGhlIE1ODQ0NMy43LiBM
U1AgUmVjYWxjdWxhdGlvbg0NSW4gTFNQIFJlY2FsY3VsYXRpb24sIExTUCB0dW5uZWxzIGJldHdl
ZW4gaW5ncmVzcyBMRVIgYW5kIG9sZCBGQSBhcmUgYnJhbmNoZWQgdG8gdGhlIG5ldyBGQS4gVGhl
IExTUiB0byBwZXJmb3JtIGJyYW5jaGluZyBmdW5jdGlvbiBpcyB1c3VhbGx5IHJlZmVycmVkIHRv
IGFzIHRoZSBjcm9zc292ZXIgTFNSLg1BZnRlciBMU1AgUmVjYWxjdWxhdGlvbiwgdGhlIHJvdXRl
IGJldHdlZW4gaW5ncmVzcyBMRVIgYW5kIG5ldyBGQSBjYW4gYmUgb3B0aW1pemVkLiBPbGQgcGF0
aCBpcyB0b3JuIGRvd24gYW5kIG5ldyBwYXRoIGlzIHNldCB1cC4gTFNQIFJlY2FsY3VsYXRpb24g
aXMgdHJpZ2dlcmVkIGJ5IHRoZSBNTi4gSXQgY2FuIGhhcHBlbiB3aGVuIHRoZSBRb1Mgb2YgTFNQ
IHR1bm5lbCBpcyB0ZW1wb3JhcmlseSBkZWdyYWRlZC4gDQ1UaGUgbWFqb3Igc3RlcHMgb2YgTFNQ
IFJlY2FsY3VsYXRpb24gaW52b2x2ZXM6DQ0xLiBEZXRlcm1pbmluZyB0aGUgbG9jYXRpb24gb2Yg
dGhlIGNyb3Nzb3ZlciBzd2l0Y2guDTIuIFNldHRpbmcgdXAgYSBuZXcgYnJhbmNoIExTUC4NMy4g
VGVybWluYXRpbmcgdGhlIG9sZCBicmFuY2ggTFNQLg0NDSAgICAgICArLS0tLSsgICAgICAgICAg
ICAgICAgICAgICAgICAgICArLS0tLSsNICAgICAgIHwgSEEgfCAgICArLS0tLS0tKyAgICstLS0t
LS0rICAgIHwgRkExfCAgICstLS0tLS0tLSsNXyAgICAgIHxMRVIxKy0tLS0rIExTUjEgKy0tLSsg
TFNSMiB8ICAgIHxMRVIyfCAgIHwgb2xkIE1OIHwNICAgICAgICstLSstKyAgICArLS0tLS0tKyAg
ICstLS0tKy0rICAgICstLS0tKyAgICstLS0tLS0tLSsNICAgICAgICAgICBcICAgICAgICAgICAg
ICAgICAgICAgIFwgICAgICAgICAgICAgICAgICB8DSAgICAgICAgICAgIFwgICAgICAgICBSZWNh
bGN1bGF0ZWQgXCAgICAgICAgICAgICAgICAgfA0gICAgICAgICAgICstKy0tLS0rICAgICAgIExT
UCAgICAgICBcICAgICAgICAgICAgICAgIHwNICAgICAgICAgICB8IExFUjMgfCAgICAgICAgICAg
ICAgICAgIFwgICAgICAgICAgICAgICB8DSAgICAgICAgICAgKy0tKy0tLSsgICAgICAgICAgICAg
ICAgICAgXCArLS0tLSsgICAgICAgVg0gICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg
ICAgICBcfCBGQTJ8ICAgKy0tLS0tLS0tKw0gICAgICAgICAgICArLSstLSsgICAgICAgICAgICAg
ICAgICAgICAgK0xFUjQrLS0tKyBOZXcgTU4gfA0gICAgICAgICAgICB8IEZOIHwgICAgICAgICAg
ICAgICAgICAgICAgKy0tLS0rICAgKy0tLS0tLS0tKw0gICAgICAgICAgICArLS0tLSsNCQ1GaWd1
cmUgOS4gTFNQIFJlY2FsY3VsYXRpb24gZm9yIE1vYmlsZSBJUA0NDQ0NTU4gICAgICAgICAgTmV3
IEZBICAgICAgT2xkIEZBICAgICAgQ3Jvc3NvdmVyICAgICAgIEhBICAgLi4uICAgRk4gDXwgICAg
ICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgTFNSICAgICAgICAgICB8ICAgICAgICAg
IHwNIHxSZWcuIFJlcXVlc3R8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8
ICAgICAgICAgIHwNIHwtLS0tLS0tLS0tLT58ICAgICAgICAgICAgIFJlZy4gUmVxdWVzdCAgICAg
ICAgICAgICB8ICAgICAgICAgIHwNIHwgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgIHwNIHwgICAgICAgICAgICB8ICAgICAgICAgICAg
IFJlZy4gUmVwbHkgICAgICAgICAgICAgICB8ICAgICAgICAgIHwNIHwgICAgICAgICAgICB8PC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18ICAgICAgICAgIHwNIHwgICAgICAg
ICAgICB8IExTUCBFeHQuICsgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgIHwN
IHwgICAgICAgICAgICB8IExTUCBSZXF1ZXN0fCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAg
ICAgICAgIHwNIHwgICAgICAgICAgICB8LS0tLS0tLS0tLS0+fCAgICAgICAgICAgIHwgICAgICAg
ICAgICB8ICAgICAgICAgIHwNIHwgICAgICAgICAgICB8IExTUCBNYXBwaW5nfCAgICAgICAgICAg
IHwgICAgICAgICAgICB8ICAgICAgICAgIHwNIHwgICAgICAgICAgICB8PC0tLS0tLS0tLS0tfCAg
ICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgIHwNIHwgUmVnLiBSZXBseSB8ICAgICAg
ICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgIHwNIHw8LS0tLS0tLS0t
LS18ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgIHwNIHwg
ICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICBNZXNzYWdlcyAg
ICAgIHwNIHwgICAgICAgICAgICB8ICAgICAgICAgICAgfCBNZXNzYWdlcyAgIHw8LS0tLS0tLS0t
LS0tLS0tLS0tLS0tLXwNIHwgICAgICAgICAgICB8IE1lc3NhZ2VzICAgfDwtLS0tLS0tLS0tLXwg
ICAgICAgICAgICB8ICAgICAgICAgIHwNIHwgTWVzc2FnZXMgICB8PC0tLS0tLS0tLS0tfCAgICAg
ICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgIHwNIHw8LS0tLS0tLS0tLS18ICAgICAgICAg
ICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgIHwNIHwgICAgICAgICAgICB8
ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgIHwNIHwgTFNQ
IFJlY2FsLiB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAg
IHwNIHwtLS0tLS0tLS0tLT58IExhYmVsIFJlcS4gKyBMU1AgUmVjYWwuIHwgICAgICAgICAgICB8
ICAgICAgICAgIHwNIHwgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAg
ICAgICAgICB8ICAgICAgICAgIHwNIHwgICAgICAgICAgICB8ICAgIExTUCBNYXBwaW5nICAgICAg
ICAgIHwgICAgICAgICAgICB8ICAgICAgICAgIHwNIHwgICAgICAgICAgICB8PC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLXwgICAgICAgICAgICB8ICAgICAgICAgIHwNIHwgICAgICAgICAgICB8ICAg
ICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgIHwNIHwgICAgICAg
ICAgICB8ICAgICAgICAgICAgfExhYmVsIFJlbC4gIHwgICAgICAgICAgICB8ICAgICAgICAgIHwN
IHwgICAgICAgICAgICB8IExhYmVsIFJlbC4gfDwtLS0tLS0tLS0tLXwgICAgICAgICAgICB8ICAg
ICAgICAgIHwNIHwgICAgICAgICAgICB8PC0tLS0tLS0tLS0tfCAgICAgICAgICAgIHwgICAgICAg
ICAgICB8ICAgICAgICAgIHwNIHwgICAgICAgICAgICB8IExhYmVsIFJlbC4gfCAgICAgICAgICAg
IHwgICAgICAgICAgICB8ICAgICAgICAgIHwNIHwgICAgICAgICAgICB8ICBSZXBseSAgICAgfCBM
YWJlbCBSZWwuIHwgICAgICAgICAgICB8ICAgICAgICAgIHwNIHwgICAgICAgICAgICB8LS0tLS0t
LS0tLS0+fCAgUmVwbHkgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgIHwNIHwgTFNQIFJlY2Fs
LiB8ICAgICAgICAgICAgfC0tLS0tLS0tLS0tPnwgICAgICAgICAgICB8ICAgICAgICAgIHwNIHwg
IFJlcGx5ICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAg
ICAgIHwNIHw8LS0tLS0tLS0tLS18ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgIE1l
c3NhZ2VzICAgICAgIHwNIHwgICAgICAgICAgICB8ICAgICAgICBNZXNzYWdlcyAgICAgICAgIHw8
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwNIHwgTWVzc2FnZXMgICB8PC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLXwgICAgICAgICAgICAgICAgICAgICAgIHwNIHw8LS0tLS0tLS0tLS18ICAgICAgICAg
ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwNIHwgICAgICAgICAgICB8
ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwNIHwgICAg
ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg
IHwNDUZpZ3VyZSAxMC4gTWVzc2FnZSBTZXF1ZW5jZSBmb3IgTFNQIFJlY2FsY3VsYXRpb24NDQ1U
aGUgTFNQIFJlY2FsY3VsYXRpb24gcHJvY2VkdXJlcyBpbiBGaWd1cmUgMTAgYXJlIGFzIGZvbGxv
d3MuDQ0tIExTUCBSZWNhbGN1bGF0aW9uIGlzIHRyaWdnZXJlZCBieSB0aGUgTU4gd2hlbiBRb1Mg
b2YgY2hhbm5lbCBvZiB0aGUgbW9iaWxlIG5vZGUgaXMgZGVncmFkZWQuDS0gTmV3IEZBIHNlbmRz
IExTUCBSZWNhbGN1bGF0aW9uIGFuZCBMYWJlbCBSZXF1ZXN0IG1lc3NhZ2UgdG8gdGhlIENyb3Nz
b3ZlciBMU1Igd2hlbiBpdCByZWNlaXZlcyBMU1AgUmVjYWxjdWxhdGlvbiBtZXNzYWdlLg0tIFRo
ZSBDcm9zc292ZXIgTFNSIHNlbmRzIExhYmVsIE1hcHBpbmcgbWVzc2FnZSB0byB0aGUgbmV3IEZB
IGFuZCByZWxlYXNlcyBleGlzdGluZyBMU1AgdG8gdGhlIG5ldyBGQSB2aWEgdGhlIG9sZCBGQS4N
LSBUaGVuLCBGQSBzZW5kcyBMU1AgUmVjYWxjdWxhdGlvbiBtZXNzYWdlIHRvIHRoZSBNTi4NDQ0N
DQ0NDQ00LiBSZXF1aXJlZCBNZXNzYWdlcyBhbmQgVExWcw0NNC4xLiBSZXF1aXJlZCBNZXNzYWdl
cyBhbmQgVExWcw0NQW55IE1lc3NhZ2VzLCBUTFZzLCBhbmQgcHJvY2VkdXJlcyBub3QgZGVmaW5l
ZCBleHBsaWNpdGx5IGluIHRoaXMgZG9jdW1lbnQgYXJlIGRlZmluZWQgaW4gdGhlIExEUCBTcGVj
aWZpY2F0aW9uIFszXSBhbmQgSVAgTW9iaWxpdHkgU3VwcG9ydCBbNF0uIEl0IGNhbiB1c2UgQ29u
c3RyYWludC1CYXNlZCBMU1AgU2V0dXAgdXNpbmcgTERQIFsyXSBhcyBhbiBpbmZvcm1hdGlvbmFs
IGRvY3VtZW50IHJlbGF0ZWQgdG8gQ1ItTERQLiANDQ00LjEuMS4gTERQIFBEVXMNDUVhY2ggTERQ
IFBEVSBpcyBhbiBMRFAgaGVhZGVyIGZvbGxvd2VkIGJ5IG9uZSBvciBtb3JlIExEUCBtZXNzYWdl
cy4gVGhlIExEUCBoZWFkZXIgaXM6DQ0wICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAg
ICAgICAgMiAgICAgICAgICAgICAgICAgICAzDTAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0
IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw18ICBWZXJzaW9uICAg
ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICBQRFUgTGVuZ3RoICAgICAgICAgICAgfA0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKyAgICAgICAgICAgICAgICAgICAgfCAgTERQIElkZW50aWZpZXIgICAgICAgICAgICAgICAg
ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwNKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNfCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0NDVZl
cnNpb24NVHdvIG9jdGV0IHVuc2lnbmVkIGludGVnZXIgY29udGFpbmluZyB2ZXJzaW9uIG51bWJl
cg0NUERVIExlbmd0aCANVHdvIG9jdGV0IGludGVnZXIgc3BlY2lmeWluZyB0aGUgdG90YWwgbGVu
Z3RoIG9mIHRoaXMgUERVIGluIG9jdGV0cw0NTERQIElkZW50aWZpZXINU2l4IG9jdGV0IGZpZWxk
IHRoYXQgdW5pcXVlbHkgaWRlbnRpZmllcyB0aGUgbGFiZWwgc3BhY2Ugb2YgdGhlIHNlbmRpbmcg
TFNSDQ0NNC4xLjIuIFR5cGUtTGVuZ3RoLVZhbHVlIEVuY29kaW5nDQ1MRFAgdXNlcyBhIFR5cGUt
TGVuZ3RoLVZhbHVlIChUTFYpIGVuY29kaW5nIHNjaGVtZSB0byBlbmNvZGUgbXVjaCBvZiB0aGUg
aW5mb3JtYXRpb24gY2FycmllZCBpbiBMRFAgbWVzc2FnZXMuDQ1BbiBMRFAgVExWIGlzIGVuY29k
ZWQgYXMgYSAyIG9jdGV0IGZpZWxkIHRoYXQgdXNlcyAxNCBiaXRzIHRvIHNwZWNpZnkgYSBUeXBl
IGFuZCAyIGJpdHMgdG8gc3BlY2lmeSBiZWhhdmlvciB3aGVuIGFuIExTUiBkb2Vzbid0IHJlY29n
bml6ZSB0aGUgVHlwZSwgZm9sbG93ZWQgYnkgYSAyIG9jdGV0IExlbmd0aCBGaWVsZCwgZm9sbG93
ZWQgYnkgYSB2YXJpYWJsZSBsZW5ndGggVmFsdWUgZmllbGQuDQ0wICAgICAgICAgICAgICAgICAg
IDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDTAgMSAyIDMgNCA1IDYg
NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Kw18VXxGfCAgICAgICAgVHlwZSAgICAgICAgICAgICAgIHwgICAgICAgICAgICBMZW5ndGggICAg
ICAgICAgICAgfA0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKw18ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA18ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBWYWx1ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA1+ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfg18ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA18
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKw18ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rDQ1VIGJpdA1Vbmtub3duIFRMViBiaXQuIEFzIGRlZmluZWQgaW4g
WzNdIA0NRiBiaXQNRm9yd2FyZCB1bmtub3duIFRMViBiaXQuIEFzIGRlZmluZWQgaW4gWzNdIA0N
VHlwZQ1FbmNvZGVzIGhvdyB0aGUgVmFsdWUgZmllbGQgaXMgdG8gYmUgaW50ZXJwcmV0ZWQuDQ1M
ZW5ndGgNU3BlY2lmaWVzIHRoZSBsZW5ndGggb2YgdGhlIFZhbHVlIGZpZWxkIGluIG9jdGV0cy4N
DVZhbHVlDU9jdGV0IHN0cmluZyBvZiBMZW5ndGggb2N0ZXRzIHRoYXQgZW5jb2RlcyBpbmZvcm1h
dGlvbiB0byBiZSBpbnRlcnByZXRlZCBhcyBzcGVjaWZpZWQgYnkgdGhlIFR5cGUgZmllbGQuDQ0N
NC4xLjMuIE1lc3NhZ2UgRm9ybWF0IGFuZCBQcm90b2NvbCBFeHRlbnNpYmlsaXR5DQ1Nb2JpbGl0
eSBTdXBwb3J0IG9mIENvbnN0cmFpbnQtYmFzZWQgTERQIGRlZmluZXMgYSBzZXQgb2YgbmV3IGNv
bnRyb2wgbWVzc2FnZXMuIEN1cnJlbnRseSwgdGhlIGZvbGxvd2luZyB0d28gbWVzc2FnZSB0eXBl
cyBhcmUgZGVmaW5lZDoNDSAgICAgMHgzRjAxICBSZWdpc3RyYXRpb24gUmVxdWVzdA0weDNGMDIg
IFJlZ2lzdHJhdGlvbiBSZXBseQ0gICAgIDB4M0YwMyAgTG9jYXRpb24gUXVlcnkNMHgzRjA0ICBM
b2NhdGlvbiBSZXNwb25zZQ0weDNGMDUgIExTUCBFeHRlbnNpb24gUmVxdWVzdA0weDNGMDYgIExT
UCBFeHRlbnNpb24gUmVwbHkNMHgzRjA3ICBMU1AgUmVjYWxjdWxhdGlvbiBSZXF1ZXN0DTB4M0Yw
OCAgTFNQIFJlY2FsY3VsYXRpb24gUmVwbHkNDQ1UaGlzIGRyYWZ0IGRlZmluZXMgYSBnZW5lcmFs
IEV4dGVuc2lvbiBtZWNoYW5pc20gdG8gYWxsb3cgb3B0aW9uYWwgaW5mb3JtYXRpb24gdG8gYmUg
Y2FycmllZCBieSBMRFAgbWVzc2FnZXMgdG8gc3VwcG9ydCBtb2JpbGl0eS4gRWFjaCBvZiB0aGVz
ZSBFeHRlbnNpb25zIGlzIGVuY29kZWQgaW4gdGhlIFRMViBmb3JtYXQuIEV4dGVuc2lvbnMgYWxs
b3cgdmFyaWFibGUgYW1vdW50cyBvZiBpbmZvcm1hdGlvbiB0byBiZSBjYXJyaWVkIHdpdGhpbiBl
YWNoIExEUCBNZXNzYWdlLiBDdXJyZW50bHksIHRoZSBmb2xsb3dpbmcgVExWIGFyZSBkZWZpbmVk
IGZvciBFeHRlbnNpb25zIGFwcGVhcmluZyBpbiBMRFAgTW9iaWxpdHkgbWVzc2FnZXM6DQ0gICAg
IDB4M0YxMSAgUmVnaXN0cmF0aW9uIFJlcXVlc3QgRGF0YSBUTFYNICAgICAwWDNGMTIgIFJlZ2lz
dHJhdGlvbiBSZXBseSBEYXRhIFRMVg0gICAgIDB4M0YxMyAgTG9jYXRpb24gUXVlcnkgRGF0YSBU
TFYgRm9ybWF0DSAgICAgICAgMHgzRjE0ICBMb2NhdGlvbiBRdWVyeSBEYXRhIFRMViBGb3JtYXQN
CTB4M0YxNSAgTFNQIEV4dGVuc2lvbiBSZXF1ZXN0IERhdGUgVExWIEZvcm1hdA0JMHgzRjE2ICBM
U1AgRXh0ZW5zaW9uIFJlcGx5IERhdGEgVExWIEZvcm1hdA0JMHgzRjE3ICBMU1AgUmVjYWxjdWxh
dGlvbiBSZXF1ZXN0IERhdGEgVExWIEZvcm1hdA0JMHgzRjE4ICBMU1AgUmVjYWxjdWxhdGlvbiBS
ZXBseSBEYXRhIFRMViBGb3JtYXQNDQ00LjIuIFJlZ2lzdHJhdGlvbiBNZXNzYWdlDQ1BIG1vYmls
ZSBub2RlIHJlZ2lzdGVycyB3aXRoIGl0cyBob21lIGFnZW50IHVzaW5nIGEgUmVnaXN0cmF0aW9u
IFJlcXVlc3QgbWVzc2FnZSBvZiBMRFAgc28gdGhhdCBpdHMgaG9tZSBhZ2VudCBjYW4gY3JlYXRl
IG9yIG1vZGlmeSBhIG1vYmlsaXR5IGJpbmRpbmcgZm9yIHRoYXQgbW9iaWxlIG5vZGUgKGUuZy4s
IHdpdGggYSBuZXcgbGlmZXRpbWUpLiBUaGUgUmVxdWVzdCBtYXkgYmUgcmVsYXllZCB0byB0aGUg
aG9tZSBhZ2VudCBieSB0aGUgZm9yZWlnbiBhZ2VudCB0aHJvdWdoIHdoaWNoIHRoZSBtb2JpbGUg
bm9kZSBpcyByZWdpc3RlcmluZy4NDQ00LjIuMS4gUmVnaXN0cmF0aW9uIFJlcXVlc3QgTWVzc2Fn
ZSBGb3JtYXQgIA0gICANVGhlIGVuY29kaW5nIGZvciB0aGUgUmVnaXN0cmF0aW9uIFJlcXVlc3Qg
TWVzc2FnZSBpczoNIA0wICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAg
ICAgICAgICAgICAgICAgICAzDTAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg
OSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw18VXwgICBNZXNzYWdlIFR5cGUgKDB4
M0YwMSkgICAgIHwgICAgICBNZXNzYWdlIExlbmd0aCAgICAgICAgICAgfA0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw18ICAg
ICAgICAgICAgICAgICAgICAgTWVzc2FnZSBJRCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgfA0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKw18ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfA0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKw18ICAgICAgICAgICAgICAgICAgICAgTWFu
ZGF0b3J5IFBhcmFtZXRlcnMgICAgICAgICAgICAgICAgICAgICAgfA0rICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKw18ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
fA0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKw18ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgfA0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgKw18ICAgICAgICAgICAgICAgICAgICAgT3B0aW9u
YWwgUGFyYW1ldGVycyAgICAgICAgICAgICAgICAgICAgICAgfA0rICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKw18ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKw0NVSBiaXQNVW5rbm93biBtZXNzYWdlIGJpdC4gIA0NTWVzc2FnZSBUeXBlDUlkZW50
aWZpZXMgdGhlIHR5cGUgb2YgbWVzc2FnZQ0NTWVzc2FnZSBMZW5ndGgNU3BlY2lmaWVzIHRoZSBj
dW11bGF0aXZlIGxlbmd0aCBpbiBvY3RldHMgb2YgdGhlIE1lc3NhZ2UgSUQsDU1hbmRhdG9yeSBQ
YXJhbWV0ZXJzLCBhbmQgT3B0aW9uYWwgUGFyYW1ldGVycy4NDU1lc3NhZ2UgSUQNMzItYml0IHZh
bHVlIHVzZWQgdG8gaWRlbnRpZnkgdGhpcyBtZXNzYWdlLiAgDQ1NYW5kYXRvcnkgUGFyYW1ldGVy
cw1WYXJpYWJsZSBsZW5ndGggc2V0IG9mIHJlcXVpcmVkIG1lc3NhZ2UgcGFyYW1ldGVycy4NDU9w
dGlvbmFsIFBhcmFtZXRlcnMNVmFyaWFibGUgbGVuZ3RoIHNldCBvZiBvcHRpb25hbCBtZXNzYWdl
IHBhcmFtZXRlcnMuICANDQ00LjIuMS4xLiBSZWdpc3RyYXRpb24gUmVxdWVzdCBEYXRhIFRMViBG
b3JtYXQNDVJlZ2lzdHJhdGlvbiBSZXF1ZXN0IERhdGEgVExWIGlzIE1hbmRhdG9yeSBQYXJhbWV0
ZXIgb2YgICAgUmVnaXN0cmF0aW9uIFJlcXVlc3QgTWVzc2FnZS4gVGhlIGVuY29kaW5nIGZvciBS
ZWdpc3RyYXRpb24gICAgUmVxdWVzdCBEYXRhIFRMViBpczoNDTAgICAgICAgICAgICAgICAgICAg
MSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNMCAxIDIgMyA0IDUgNiA3
IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
DXxVfEZ8ICAgICAgIFR5cGUgKDB4M0YxMSkgICAgICAgfCAgICAgICAgICAgIExlbmd0aCAgICAg
ICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rDXxTfEJ8RHxNfEd8VnwgICAgIHJlc2VydmVkICAgICAgfCAgICAg
ICAgICBMaWZldGltZSAgICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwgICAgICAgICAgICAgICAgICAg
ICAgICAgIEhvbWUgQWRkcmVzcyAgICAgICAgICAgICAgICAgICAgICAgICB8DSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwg
ICAgICAgICAgICAgICAgICAgICAgICAgICBIb21lIEFnZW50ICAgICAgICAgICAgICAgICAgICAg
ICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rDXwgICAgICAgICAgICAgICAgICAgICAgICBDYXJlLW9mIEFkZHJlc3Mg
ICAgICAgICAgICAgICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DSsgICAgICAgICAgICAg
ICAgICAgICAgICAgSWRlbnRpZmljYXRpb24gICAgICAgICAgICAgICAgICAgICAgICArDXwgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rDQ1VIGJpdA1Vbmtub3duIFRMViBiaXQuICANDUYgYml0DUZvcndhcmQgdW5r
bm93biBUTFYgYml0LiAgDQ1UeXBlDTB4M0YxMQ0NTGVuZ3RoDVNwZWNpZmllcyB0aGUgbGVuZ3Ro
IG9mIHRoZSBWYWx1ZSBmaWVsZCBpbiBvY3RldHMuDQ1TIGJpdCAgICAgICAgDVNpbXVsdGFuZW91
cyBiaW5kaW5ncy4gQXMgZGVzY3JpYmVkIGluIFs1XS4gDQ1CIGJpdA1Ccm9hZGNhc3QgZGF0YWdy
YW1zLiBBcyBkZXNjcmliZWQgaW4gWzVdLiANDUQgYml0DURlY2Fwc3VsYXRpb24gYnkgbW9iaWxl
IG5vZGUuIEFzIGRlc2NyaWJlZCBpbiBbNV0uDQ1NIGJpdA1NaW5pbWFsIGVuY2Fwc3VsYXRpb24u
IEFzIGRlc2NyaWJlZCBpbiBbNV0uDQ1HIGJpdCAgDUdSRSBlbmNhcHN1bGF0aW9uLiBBcyBkZXNj
cmliZWQgaW4gWzVdLg0NViBiaXQgDUFzIGRlc2NyaWJlZCBpbiBbNV0uDQ1yZXNlcmVkDVJlc2Vy
dmVkIGJpdHM7IHNlbnQgYXMgemVybw0NTGlmZXRpbWUNQXMgZGVzY3JpYmVkIGluIFs1XS4NDUhv
bWUgQWRkcmVzcw1UaGUgSVAgYWRkcmVzcyBvZiB0aGUgbW9iaWxlIG5vZGUuDQ1Ib21lIEFnZW50
DVRoZSBJUCBhZGRyZXNzIG9mIHRoZSBtb2JpbGUgbm9kZSdzIGhvbWUgYWdlbnQuDQ1DYXJlLW9m
IEFkZHJlc3MNVGhlIElQIGFkZHJlc3MgZm9yIHRoZSBlbmQgb2YgdGhlIExTUCB0dW5uZWwuDQ1J
ZGVudGlmaWNhdGlvbg1BcyBkZXNjcmliZWQgaW4gWzVdLiAgDQ0NNC4yLjIuIFJlZ2lzdHJhdGlv
biBSZXBseQ0NQSBtb2JpbGl0eSBhZ2VudCByZXR1cm5zIGEgUmVnaXN0cmF0aW9uIFJlcGx5IG1l
c3NhZ2UgdG8gYSBtb2JpbGUgbm9kZSB3aGljaCBoYXMgc2VudCBhIFJlZ2lzdHJhdGlvbiBSZXF1
ZXN0IG1lc3NhZ2UuIElmICAgdGhlIG1vYmlsZSBub2RlIGlzIHJlcXVlc3Rpbmcgc2VydmljZSBm
cm9tIGEgZm9yZWlnbiBhZ2VudCwgdGhhdCBmb3JlaWduIGFnZW50IHdpbGwgcmVjZWl2ZSB0aGUg
UmVwbHkgZnJvbSB0aGUgaG9tZSBhZ2VudCBhbmQgc3Vic2VxdWVudGx5IHJlbGF5IGl0IHRvIHRo
ZSBtb2JpbGUgbm9kZS4gVGhlIFJlcGx5IG1lc3NhZ2UgY29udGFpbnMgdGhlIG5lY2Vzc2FyeSBj
b2RlcyB0byBpbmZvcm0gdGhlIG1vYmlsZSBub2RlIGFib3V0IHRoZSBzdGF0dXMgb2YgaXRzIFJl
cXVlc3QsIGFsb25nIHdpdGggdGhlIGxpZmV0aW1lIGdyYW50ZWQgYnkgdGhlIGhvbWUgYWdlbnQs
IGFzIGRlc2NyaWJlZCBpbiBbNV0uDQ0NNC4yLjIuMS4gUmVnaXN0cmF0aW9uIFJlcGx5IE1lc3Nh
Z2UgRm9ybWF0DQ1SZWdpc3RyYXRpb24gUmVwbHkgTWVzc2FnZSBoYXMgZm9sbG93aW5nIGZvcm1h
dDoNICAgDTAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAg
ICAgICAgICAgIDMNMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy
IDMgNCA1IDYgNyA4IDkgMCAxDSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXxVfCAgIE1lc3NhZ2UgVHlwZSAoMHgzRjAyKSAg
ICAgfCAgICAgIE1lc3NhZ2UgTGVuZ3RoICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwgICAgICAgICAg
ICAgICAgICAgICBNZXNzYWdlIElEICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rDXwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB8DSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICArDXwgICAgICAgICAgICAgICAgICAgICBNYW5kYXRvcnkg
UGFyYW1ldGVycyAgICAgICAgICAgICAgICAgICAgICB8DSsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArDXwgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rDXwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB8DSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICArDXwgICAgICAgICAgICAgICAgICAgICBPcHRpb25hbCBQYXJh
bWV0ZXJzICAgICAgICAgICAgICAgICAgICAgICB8DSsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArDXwgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
DQ1VIGJpdA1Vbmtub3duIG1lc3NhZ2UgYml0LiAgDQ1NZXNzYWdlIFR5cGUNSWRlbnRpZmllcyB0
aGUgdHlwZSBvZiBtZXNzYWdlDQ1NZXNzYWdlIExlbmd0aA1TcGVjaWZpZXMgdGhlIGN1bXVsYXRp
dmUgbGVuZ3RoIGluIG9jdGV0cyBvZiB0aGUgTWVzc2FnZSBJRCwgICAgIE1hbmRhdG9yeSBQYXJh
bWV0ZXJzLCBhbmQgT3B0aW9uYWwgUGFyYW1ldGVycy4NDU1lc3NhZ2UgSUQNMzItYml0IHZhbHVl
IHVzZWQgdG8gaWRlbnRpZnkgdGhpcyBtZXNzYWdlLiAgDQ1NYW5kYXRvcnkgUGFyYW1ldGVycw1W
YXJpYWJsZSBsZW5ndGggc2V0IG9mIHJlcXVpcmVkIG1lc3NhZ2UgcGFyYW1ldGVycy4NDU9wdGlv
bmFsIFBhcmFtZXRlcnMNVmFyaWFibGUgbGVuZ3RoIHNldCBvZiBvcHRpb25hbCBtZXNzYWdlIHBh
cmFtZXRlcnMuICANDQ00LjIuMi4yIFJlZ2lzdHJhdGlvbiBSZXBseSBEYXRhIFRMViBGb3JtYXQN
DVRoZSBlbmNvZGluZyBmb3IgdGhlIFJlZ2lzdHJhdGlvbiBSZXBseSBEYXRhIFRMViBpczoNDTAg
ICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAg
IDMNMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg
NyA4IDkgMCAxDSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rDXxVfEZ8ICAgICAgIFR5cGUgKDB4M0YxMikgICAgICAgfCAgICAg
ICAgICAgIExlbmd0aCAgICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwgICAgIENvZGUgICAgIHwgICAg
IHJlc2VydmVkICAgfCAgICAgICAgICAgTGlmZXRpbWUgICAgICAgICAgICB8DSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwg
ICAgICAgICAgICAgICAgICAgICAgICAgIEhvbWUgQWRkcmVzcyAgICAgICAgICAgICAgICAgICAg
ICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rDXwgICAgICAgICAgICAgICAgICAgICAgICAgICBIb21lIEFnZW50ICAg
ICAgICAgICAgICAgICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DSsgICAgICAgICAgICAg
ICAgICAgICAgICAgSWRlbnRpZmljYXRpb24gICAgICAgICAgICAgICAgICAgICAgICB8DXwgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICArDSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rDQ1VIGJpdA1Vbmtub3duIFRMViBiaXQuICANDUYgYml0DUZvcndhcmQgdW5r
bm93biBUTFYgYml0LiAgDQ1UeXBlDTB4M0YxMg0NTGVuZ3RoDVNwZWNpZmllcyB0aGUgbGVuZ3Ro
IG9mIHRoZSBWYWx1ZSBmaWVsZCBpbiBvY3RldHMuDQ1Db2RlICAgICANQSB2YWx1ZSBpbmRpY2F0
aW5nIHRoZSByZXN1bHQgb2YgdGhlIFJlZ2lzdHJhdGlvbiBSZXF1ZXN0IE1lc3NhZ2UuICANDUxp
ZmV0aW1lDUFzIGRlc2NyaWJlZCBpbiBbNV0uDQ1Ib21lIEFkZHJlc3MNVGhlIElQIGFkZHJlc3Mg
b2YgdGhlIG1vYmlsZSBub2RlLg0NSG9tZSBBZ2VudA1UaGUgSVAgYWRkcmVzcyBvZiB0aGUgbW9i
aWxlIG5vZGUncyBob21lIGFnZW50Lg0NSWRlbnRpZmljYXRpb24NQXMgZGVzY3JpYmVkIGluIFs1
XS4NDVRoZSBmb2xsb3dpbmcgdmFsdWVzIGFyZSBkZWZpbmVkIGZvciB1c2Ugd2l0aGluIHRoZSBD
b2RlIGZpZWxkLg1SZWdpc3RyYXRpb24gc3VjY2Vzc2Z1bDoNDTAgcmVnaXN0cmF0aW9uIGFjY2Vw
dGVkDTEgcmVnaXN0cmF0aW9uIGFjY2VwdGVkLCBidXQgc2ltdWx0YW5lb3VzIG1vYmlsaXR5IGJp
bmRpbmdzIHVuc3VwcG9ydGVkDQ1SZWdpc3RyYXRpb24gZGVuaWVkIGJ5IHRoZSBmb3JlaWduIGFn
ZW50IGFuZCB0aGUgaG9tZSBhZ2VudCBpcyBzcGVjaWZpZWQgaW4gWzVdLg0NDTQuMy4gQWdlbnQg
QWR2ZXJ0aXNlbWVudCBhbmQgU29saWNpdGF0aW9uIE1lc3NhZ2VzDQ1UaGUgQWdlbnQgQWR2ZXJ0
aXNlbWVudCBhbmQgU29saWNpdGF0aW9uIE1lc3NhZ2VzIGFyZSBlbmNhcHN1bGF0ZWQgYnkgdGhl
IE1QTFMgc2hpbSBoZWFkZXIgd2hpbGUgYSBNTiB0cmllcyB0byBkaXNjb3ZlciB0aGUgSEEgb3Ig
RkEgdGhyb3VnaCB0aGUgTVBMUyBuZXR3b3JrLiAoSXQgbWF5IGJlIG9wdGlvbmFsbHkgYXBwbGll
ZCB0byBTY2VuYXJpbyAyLikNDU1QTFMgc2hpbSBoZWFkZXINDTIwICAgICAgICAgICAgICAgICAg
ICAgICAgICAzICAgMSAgICAgICA4DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwgICAgICAgICAgICAgTGFiZWwgICAgICAg
ICAgICAgICAgICAgICB8IEV4cCB8U3wgICAgIFRUTCAgICAgICB8DSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDSAgICAgICAg
DSAgICBMYWJlbCAgICAgIFNvbWUgcmVzZXJ2ZWQgdmFsdWUgZm9yIE1vYmlsZSBJUA0NICAgIEV4
cCAgICAgICAgZXhwZXJpbWVudGFsIHVzZQ0NICAgIFMgICAgICAgICAgYm90dG9tIG9mIHN0YWNr
DSAgICAgICANICAgIFRUTCAgICAgICAgdGhlIFRpbWUgdG8gbGl2ZSBmb3IgYWxsIEFnZW50IEFk
dmVydGlzZW1lbnRzIE1VU1QgYmUgc2V0DXRvIDEuDQ0NSUNNUCBBZ2VudCBBZHZlcnRpc2VtZW50
IE1lc3NhZ2UNDTAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAg
ICAgICAgICAgICAgIDMNMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg
MSAyIDMgNCA1IDYgNyA4IDkgMCAxDSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwgICAgIFR5cGUgICAgICB8ICAgICBDb2Rl
ICAgICAgfCAgICAgICAgICAgQ2hlY2tzdW0gICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwgICBOdW0g
QWRkcnMgICB8QWRkciBFbnRyeSBTaXplfCAgICAgICAgICAgTGlmZXRpbWUgICAgICAgICAgICB8
DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rDXwgICAgICAgICAgICAgICAgICAgICAgIFJvdXRlciBBZGRyZXNzWzFdICAgICAg
ICAgICAgICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwgICAgICAgICAgICAgICAgICAgICAgUHJlZmVy
ZW5jZSBMZXZlbFsxXSAgICAgICAgICAgICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwgICAgICAgICAg
ICAgICAgICAgICAgIFJvdXRlciBBZGRyZXNzWzJdICAgICAgICAgICAgICAgICAgICAgICB8DSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rDXwgICAgICAgICAgICAgICAgICAgICAgUHJlZmVyZW5jZSBMZXZlbFsyXSAgICAgICAg
ICAgICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQ0gICAgSUNNUCBGaWVsZHM6DQ0gICAgICBUeXBlICAg
ICAgICAgICAgICAgICAgOQ0NICAgICAgQ29kZSAgICAgICAgICAgICAgICAgIDEgKG5vdGU6IGV4
dGVuZGVkIGZvciBBZ2VudCBEaXNjb3ZlcnkpDQ0gICAgICBDaGVja3N1bSAgICAgICAgICAgICAg
QXMgZGVzY3JpYmVkIGluIFsxMV0uDQ0gICAgICBOdW0gQWRkcnMgICAgICAgICAgICAgVGhlIG51
bWJlciBvZiByb3V0ZXIgYWRkcmVzc2VzIGFkdmVydGlzZWQNICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGluIHRoaXMgbWVzc2FnZS4NDSAgICAgIEFkZHIgRW50cnkgU2l6ZSAgICAgICBBcyBk
ZXNjcmliZWQgaW4gWzExXS4NDSAgICAgIExpZmV0aW1lICAgICAgICAgICAgICBUaGUgbWF4aW11
bSBudW1iZXIgb2Ygc2Vjb25kcyB0aGF0IHRoZQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAg
cm91dGVyIGFkZHJlc3NlcyBtYXkgYmUgY29uc2lkZXJlZCB2YWxpZC4NDSAgICAgIFJvdXRlciBB
ZGRyZXNzW2ldLCAgICBNb2JpbGUgQWdlbnSScyBJUCBhZGRyZXNzLg0JaT0xLi5OdW0gQWRkcnMN
DSAgICAgIFByZWZlcmVuY2UgTGV2ZWxbaV0sICBBcyBkZXNjcmliZWQgaW4gWzExXS4NCWk9MS4u
TnVtIEFkZHJzDQ0NSUNNUCBBZ2VudCBTb2xpY2l0YXRpb24gTWVzc2FnZQ0NMCAgICAgICAgICAg
ICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0wIDEgMiAz
IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEN
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSsNfCAgICAgVHlwZSAgICAgIHwgICAgIENvZGUgICAgICB8ICAgICAgICAgICBDaGVj
a3N1bSAgICAgICAgICAgIHwNKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNfCAgICAgICAgICAgICAgICAgICAgICAgICAgIFJl
c2VydmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNDSAgIElDTVAgRmll
bGRzOg0NICAgICAgVHlwZSAgICAgICAgICAgICAgICAgIDEwDQ0gICAgICBDb2RlICAgICAgICAg
ICAgICAgICAgMSAobm90ZTogZXh0ZW5kZWQgZm9yIEFnZW50IERpc2NvdmVyeSkNDSAgICAgIENo
ZWNrc3VtICAgICAgICAgICAgICBBcyBzcGVjaWZpZWQgaW4gWzExXS4NDSAgICAgIFJlc2VydmVk
ICAgICAgICAgICAgICBTZW50IGFzIDA7IGlnbm9yZWQgb24gcmVjZXB0aW9uLg0NDTQuNC4gTG9j
YXRpb24gUXVlcnkgYW5kIFJlc3BvbnNlIE1lc3NhZ2VzDQ1BIExFUiB3aXNoaW5nIHRvIHNlbmQg
YSBwYWNrZXQgdG8gdGhlIG1vYmlsZSBub2RlIGZvciB0aGUgZmlyc3QgdGltZSBtdXN0IGZpcnN0
IGRpc2NvdmVyIHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBtb2JpbGUgaG9zdCdzIEhBLiBUaGUgTEVS
IHRoZW4gaXNzdWVzIGEgcXVlcnkgdG8gdGhlIEhBLCB3aGljaCByZXR1cm5zIHRoZSBtb2JpbGUg
aG9zdCdzIExvY2F0aW9uIGFzIHdlbGwgYXMgdGhlIHJlbWFpbmluZyByZWdpc3RyYXRpb24gTGlm
ZXRpbWUuIFRoZSBMRVIgY2FzaGVzIHRoZSBtb2JpbGUgbm9kZSdzIExvY2F0aW9uIGFuZCB1c2Vz
IHRoZSBjYWNoZWQgYmluZGluZyBmb3Igc3Vic2VxdWVudCBwYWNrZXRzIGRlc3RpbmVkIHRvIHRo
ZSBtb2JpbGUgbm9kZS4gVGhlIExFUiBNdXN0IHJlZnJlc2ggaXRzIGJpbmRpbmcgY2FjaGUgYnkg
cXVlcnlpbmcgdGhlIEhBIGFnYWluIGJlZm9yZSB0aGUgbW9iaWxlIG5vZGUncyByZW1haW5pbmcg
cmVnaXN0cmF0aW9uIExpZmV0aW1lIGV4cGlyZXMuDQ0NNC40LjEuIExvY2F0aW9uIFF1ZXJ5IE1l
c3NhZ2UgRm9ybWF0DSANIFRoZSBlbmNvZGluZyBmb3IgdGhlIExvY2F0aW9uIFF1ZXJ5IE1lc3Nh
Z2UgaXM6DSANMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAg
ICAgICAgICAgICAgMw0wIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx
IDIgMyA0IDUgNiA3IDggOSAwIDENKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNfFV8ICAgTWVzc2FnZSBUeXBlICgweDNGMDMp
ICAgICB8ICAgICAgTWVzc2FnZSBMZW5ndGggICAgICAgICAgIHwNKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNfCAgICAgICAg
ICAgICAgICAgICAgIE1lc3NhZ2UgSUQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSsNfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHwNKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICsNfCAgICAgICAgICAgICAgICAgICAgIE1hbmRhdG9y
eSBQYXJhbWV0ZXJzICAgICAgICAgICAgICAgICAgICAgIHwNKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsNfCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSsNfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwNKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICsNfCAgICAgICAgICAgICAgICAgICAgIE9wdGlvbmFsIFBh
cmFtZXRlcnMgICAgICAgICAgICAgICAgICAgICAgIHwNKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsNfCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSsNDVUgYml0DVVua25vd24gbWVzc2FnZSBiaXQuICANDU1lc3NhZ2UgVHlwZQ1JZGVudGlmaWVz
IHRoZSB0eXBlIG9mIG1lc3NhZ2UNDU1lc3NhZ2UgTGVuZ3RoDVNwZWNpZmllcyB0aGUgY3VtdWxh
dGl2ZSBsZW5ndGggaW4gb2N0ZXRzIG9mIHRoZSBNZXNzYWdlIElELA1NYW5kYXRvcnkgUGFyYW1l
dGVycywgYW5kIE9wdGlvbmFsIFBhcmFtZXRlcnMuDQ1NZXNzYWdlIElEDTMyLWJpdCB2YWx1ZSB1
c2VkIHRvIGlkZW50aWZ5IHRoaXMgbWVzc2FnZS4gIA0NTWFuZGF0b3J5IFBhcmFtZXRlcnMNVmFy
aWFibGUgbGVuZ3RoIHNldCBvZiByZXF1aXJlZCBtZXNzYWdlIHBhcmFtZXRlcnMuDQ1PcHRpb25h
bCBQYXJhbWV0ZXJzDVZhcmlhYmxlIGxlbmd0aCBzZXQgb2Ygb3B0aW9uYWwgbWVzc2FnZSBwYXJh
bWV0ZXJzLiAgDQ0NNC40LjIuIExvY2F0aW9uIFF1ZXJ5IERhdGEgVExWIEZvcm1hdA0NTG9jYXRp
b24gUXVlcnkgRGF0YSBUTFYgaXMgTWFuZGF0b3J5IFBhcmFtZXRlciBvZiBMb2NhdGlvbiBRdWVy
eSBNZXNzYWdlLiBUaGUgZW5jb2RpbmcgZm9yIExvY2F0aW9uIFF1ZXJ5IERhdGEgVExWIGlzOg0N
MCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAg
ICAgMw0wIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg
NiA3IDggOSAwIDENKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSsNfFV8RnwgICAgICAgVHlwZSAoMHgzRjEzKSAgICAgICB8ICAg
ICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgIHwNKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNfCAgICAgICAgICAgICAgICAg
ICAgICAgICAgSG9tZSBBZGRyZXNzICAgICAgICAgICAgICAgICAgICAgICAgIHwNKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN
DVUgYml0DVVua25vd24gVExWIGJpdC4gIA0NRiBiaXQNRm9yd2FyZCB1bmtub3duIFRMViBiaXQu
ICANDVR5cGUNSWRlbnRpZmllcyB0aGUgdHlwZSBvZiBtZXNzYWdlDQ1MZW5ndGgNU3BlY2lmaWVz
IHRoZSBsZW5ndGggb2YgdGhlIFZhbHVlIGZpZWxkIGluIG9jdGV0cy4NIA1Ib21lIEFkZHJlc3MN
VGhlIElQIGFkZHJlc3Mgb2YgdGhlIG1vYmlsZSBub2RlLg0NDTQuNC4zLiBMb2NhdGlvbiBSZXNw
b25zZSBNZXNzYWdlIEZvcm1hdA0gDSBUaGUgZW5jb2RpbmcgZm9yIHRoZSBMb2NhdGlvbiBSZXNw
b25zZSBNZXNzYWdlIGlzOg0gDTAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAg
ICAyICAgICAgICAgICAgICAgICAgIDMNMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2
IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXxVfCAgIE1lc3NhZ2UgVHlw
ZSAoMHgzRjA0KSAgICAgfCAgICAgIE1lc3NhZ2UgTGVuZ3RoICAgICAgICAgICB8DSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
DXwgICAgICAgICAgICAgICAgICAgICBNZXNzYWdlIElEICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rDXwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB8DSsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArDXwgICAgICAgICAgICAgICAgICAg
ICBNYW5kYXRvcnkgUGFyYW1ldGVycyAgICAgICAgICAgICAgICAgICAgICB8DSsgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArDXwg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rDXwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8DSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArDXwgICAgICAgICAgICAgICAgICAgICBP
cHRpb25hbCBQYXJhbWV0ZXJzICAgICAgICAgICAgICAgICAgICAgICB8DSsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArDXwgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rDQ1VIGJpdA1Vbmtub3duIG1lc3NhZ2UgYml0LiAgDQ1NZXNzYWdlIFR5cGUN
SWRlbnRpZmllcyB0aGUgdHlwZSBvZiBtZXNzYWdlDQ1NZXNzYWdlIExlbmd0aA1TcGVjaWZpZXMg
dGhlIGN1bXVsYXRpdmUgbGVuZ3RoIGluIG9jdGV0cyBvZiB0aGUgTWVzc2FnZSBJRCwNTWFuZGF0
b3J5IFBhcmFtZXRlcnMsIGFuZCBPcHRpb25hbCBQYXJhbWV0ZXJzLg0NTWVzc2FnZSBJRA0zMi1i
aXQgdmFsdWUgdXNlZCB0byBpZGVudGlmeSB0aGlzIG1lc3NhZ2UuICANDU1hbmRhdG9yeSBQYXJh
bWV0ZXJzDVZhcmlhYmxlIGxlbmd0aCBzZXQgb2YgcmVxdWlyZWQgbWVzc2FnZSBwYXJhbWV0ZXJz
Lg0NT3B0aW9uYWwgUGFyYW1ldGVycw1WYXJpYWJsZSBsZW5ndGggc2V0IG9mIG9wdGlvbmFsIG1l
c3NhZ2UgcGFyYW1ldGVycy4gIA0NDTQuNC40LiBMb2NhdGlvbiBSZXNwb25zZSBEYXRhIFRMViBG
b3JtYXQNDUxvY2F0aW9uIFJlc3BvbnNlIERhdGEgVExWIGlzIE1hbmRhdG9yeSBQYXJhbWV0ZXIg
b2YgTG9jYXRpb24gUmVzcG9uc2UgTWVzc2FnZS4gVGhlIGVuY29kaW5nIGZvciBMb2NhdGlvbiBS
ZXNwb25zZSBEYXRhIFRMViBpczoNDTAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAg
ICAgICAyICAgICAgICAgICAgICAgICAgIDMNMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQg
NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXxVfEZ8ICAgICAgIFR5
cGUgKDB4M0YxNCkgICAgICAgfCAgICAgICAgICAgIExlbmd0aCAgICAgICAgICAgICB8DSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rDXwgICAgICAgICAgIHJlc2VydmVkICAgICAgICAgICAgfCAgICAgICAgICBMaWZldGltZSAg
ICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rDXwgICAgICAgICAgICAgICAgICAgICAgICAgIEhvbWUgQWRk
cmVzcyAgICAgICAgICAgICAgICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwgICAgICAgICAgICAgICAg
ICAgICAgICBDYXJlLW9mIEFkZHJlc3MgICAgICAgICAgICAgICAgICAgICAgICB8DSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
DQ1VIGJpdA1Vbmtub3duIFRMViBiaXQuICANDUYgYml0DUZvcndhcmQgdW5rbm93biBUTFYgYml0
LiAgDQ1UeXBlDUlkZW50aWZpZXMgdGhlIHR5cGUgb2YgbWVzc2FnZQ0NTGVuZ3RoDVNwZWNpZmll
cyB0aGUgbGVuZ3RoIG9mIHRoZSBWYWx1ZSBmaWVsZCBpbiBvY3RldHMuDQ1MaWZldGltZQ1UaGUg
bnVtYmVyIG9mIHNlY29uZHMgcmVtYWluaW5nIGJlZm9yZSB0aGUgcmVnaXN0cmF0aW9uIGlzIGNv
bnNpZGVyZWQgZXhwaXJlZC4gDSANSG9tZSBBZGRyZXNzDVRoZSBJUCBhZGRyZXNzIG9mIHRoZSBt
b2JpbGUgbm9kZS4NDUNhcmUtb2YgQWRkcmVzcw1UaGUgSVAgYWRkcmVzcyBmb3IgdGhlIGVuZCBv
ZiB0aGUgTFNQIHR1bm5lbC4NDQ00LjUuIExTUCBFeHRlbnNpb24gTWVzc2FnZQ0NVGhlIGVuY29k
aW5nIGZvciB0aGUgTFNQIEV4dGVuc2lvbiBNZXNzYWdlIGlzOg0gDTAgICAgICAgICAgICAgICAg
ICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNMCAxIDIgMyA0IDUg
NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rDXxVfCAgIE1lc3NhZ2UgVHlwZSAgICAgICAgICAgICAgfCAgICAgIE1lc3NhZ2UgTGVuZ3Ro
ICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rDXwgICAgICAgICAgICAgICAgICAgICBNZXNzYWdlIElEICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DSsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr
DXwgICAgICAgICAgICAgICAgICAgICBNYW5kYXRvcnkgUGFyYW1ldGVycyAgICAgICAgICAgICAg
ICAgICAgICB8DSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICArDXwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DSsgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArDXwg
ICAgICAgICAgICAgICAgICAgICBPcHRpb25hbCBQYXJhbWV0ZXJzICAgICAgICAgICAgICAgICAg
ICAgICB8DSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICArDXwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQ1VIGJpdA1Vbmtub3duIG1lc3NhZ2Ug
Yml0LiAgDQ1NZXNzYWdlIFR5cGUNSWRlbnRpZmllcyB0aGUgdHlwZSBvZiBtZXNzYWdlDQ1JbiB0
aGUgY2FzZSBvZiBMU1AgRXh0ZW5zaW9uIFJlcXVlc3QsIE1lc3NhZ2UgVHlwZSB2YWx1ZSBpcyAw
eDNGMDUuIElmIE1lc3NhZ2UgVHlwZSBmaWVsZCB2YWx1ZWQgaXMgMHgzRjA2LCB0aGVuIHRoaXMg
bWVzc2FnZSBpcyBMU1AgRXh0ZW5zaW9uIFJlcGx5IE1lc3NhZ2UgaW4gcmVzcG9uc2UgdG8gTFNQ
IEV4dGVuc2lvbiBSZXF1ZXN0Lg0NTWVzc2FnZSBMZW5ndGgNU3BlY2lmaWVzIHRoZSBjdW11bGF0
aXZlIGxlbmd0aCBpbiBvY3RldHMgb2YgdGhlIE1lc3NhZ2UgSUQsDU1hbmRhdG9yeSBQYXJhbWV0
ZXJzLCBhbmQgT3B0aW9uYWwgUGFyYW1ldGVycy4NDU1lc3NhZ2UgSUQNMzItYml0IHZhbHVlIHVz
ZWQgdG8gaWRlbnRpZnkgdGhpcyBtZXNzYWdlLiAgDQ1NYW5kYXRvcnkgUGFyYW1ldGVycw1WYXJp
YWJsZSBsZW5ndGggc2V0IG9mIHJlcXVpcmVkIG1lc3NhZ2UgcGFyYW1ldGVycy4NDU9wdGlvbmFs
IFBhcmFtZXRlcnMNVmFyaWFibGUgbGVuZ3RoIHNldCBvZiBvcHRpb25hbCBtZXNzYWdlIHBhcmFt
ZXRlcnMuICANDQ00LjUuMS4gTFNQIEV4dGVuc2lvbiBEYXRhIFRMViBGb3JtYXQNDUxTUCBFeHRl
bnNpb24gRGF0YSBUTFYgaXMgTWFuZGF0b3J5IFBhcmFtZXRlciBvZiBMU1AgRXh0ZW5zaW9uIE1l
c3NhZ2UuIFRoZSBlbmNvZGluZyBmb3IgTFNQIEV4dGVuc2lvbiBEYXRhIFRMViBpczoNDTAgICAg
ICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMN
MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4
IDkgMCAxDSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rDXxVfEZ8ICAgICAgIFR5cGUgICAgICAgICAgICAgICAgfCAgICAgICAg
ICAgIExlbmd0aCAgICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwgICAgICAgICAgICAgICAgICAgICAg
ICAgIEhvbWUgQWRkcmVzcyAgICAgICAgICAgICAgICAgICAgICAgICB8DSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDXwgICAg
ICAgICAgICAgICAgICAgICAgICAgT2xkIEZBIEFkZHJlc3MgICAgICAgICAgICAgICAgICAgICAg
ICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rDXwgICAgICAgICAgICAgICAgICAgICAgICAgTmV3IEZBIEFkZHJlc3MgICAg
ICAgICAgICAgICAgICAgICAgICB8DSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQ0NVSBiaXQNVW5rbm93biBUTFYgYml0LiAg
DQ1GIGJpdA1Gb3J3YXJkIHVua25vd24gVExWIGJpdC4gIA0NVHlwZQ1JZGVudGlmaWVzIHRoZSB0
eXBlIG9mIG1lc3NhZ2UNSW4gdGhlIGNhc2Ugb2YgTFNQIEV4dGVuc2lvbiBSZXF1ZXN0IERhdGEg
VExWLCBUeXBlIHZhbHVlIGlzIDB4M0YxNS4gSWYgVHlwZSBmaWVsZCB2YWx1ZWQgaXMgMHgzRjE2
LCB0aGVuIHRoaXMgVExWIGlzIExTUCBFeHRlbnNpb24gUmVwbHkgRGF0YSBUTFYgaW4gcmVzcG9u
c2UgdG8gTFNQIEV4dGVuc2lvbiBSZXF1ZXN0IERhdGEgVExWLg0NTGVuZ3RoDVNwZWNpZmllcyB0
aGUgbGVuZ3RoIG9mIHRoZSBWYWx1ZSBmaWVsZCBpbiBvY3RldHMuDSANSG9tZSBBZGRyZXNzDVRo
ZSBJUCBhZGRyZXNzIG9mIHRoZSBtb2JpbGUgbm9kZS4NDU9sZCBGQSBBZGRyZXNzDVRoZSBJUCBh
ZGRyZXNzIG9mIHRoZSBvbGQgRkEuDQ1OZXcgRkEgQWRkcmVzcw1UaGUgSVAgYWRkcmVzcyBvZiB0
aGUgTmV3IEZBLg0NDTQuNi4gTFNQIFJlY2FsY3VsYXRpb24gTWVzc2FnZQ0NIFRoZSBlbmNvZGlu
ZyBmb3IgdGhlIExTUCBSZWNhbGN1bGF0aW9uIE1lc3NhZ2UgaXM6DSANMCAgICAgICAgICAgICAg
ICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0wIDEgMiAzIDQg
NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSsNfFV8ICAgTWVzc2FnZSBUeXBlICAgICAgICAgICAgICB8ICAgICAgTWVzc2FnZSBMZW5n
dGggICAgICAgICAgIHwNKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNfCAgICAgICAgICAgICAgICAgICAgIE1lc3NhZ2UgSUQg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNfCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICsNfCAgICAgICAgICAgICAgICAgICAgIE1hbmRhdG9yeSBQYXJhbWV0ZXJzICAgICAgICAgICAg
ICAgICAgICAgIHwNKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICsNfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNfCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsN
fCAgICAgICAgICAgICAgICAgICAgIE9wdGlvbmFsIFBhcmFtZXRlcnMgICAgICAgICAgICAgICAg
ICAgICAgIHwNKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICsNfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHwNKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNDVUgYml0DVVua25vd24gbWVzc2Fn
ZSBiaXQuICANDU1lc3NhZ2UgVHlwZQ1JZGVudGlmaWVzIHRoZSB0eXBlIG9mIG1lc3NhZ2UNDUlu
IHRoZSBjYXNlIG9mIExTUCBSZWNhbGN1bGF0aW9uIFJlcXVlc3QgTWVzc2FnZSwgTWVzc2FnZSBU
eXBlIHZhbHVlIGlzIDB4M0YwNy4gSWYgTWVzc2FnZSBUeXBlIGZpZWxkIHZhbHVlZCBpcyAweDNG
MDgsIHRoZW4gdGhpcyBtZXNzYWdlIGlzIExTUCBSZWNhbGN1bGF0aW9uIFJlcGx5IE1lc3NhZ2Ug
aW4gcmVzcG9uc2UgdG8gTFNQIFJlY2FsY3VsYXRpb24gUmVxdWVzdC4NDU1lc3NhZ2UgTGVuZ3Ro
DVNwZWNpZmllcyB0aGUgY3VtdWxhdGl2ZSBsZW5ndGggaW4gb2N0ZXRzIG9mIHRoZSBNZXNzYWdl
IElELA1NYW5kYXRvcnkgUGFyYW1ldGVycywgYW5kIE9wdGlvbmFsIFBhcmFtZXRlcnMuDQ1NZXNz
YWdlIElEDTMyLWJpdCB2YWx1ZSB1c2VkIHRvIGlkZW50aWZ5IHRoaXMgbWVzc2FnZS4gIA0NTWFu
ZGF0b3J5IFBhcmFtZXRlcnMNVmFyaWFibGUgbGVuZ3RoIHNldCBvZiByZXF1aXJlZCBtZXNzYWdl
IHBhcmFtZXRlcnMuDQ1PcHRpb25hbCBQYXJhbWV0ZXJzDVZhcmlhYmxlIGxlbmd0aCBzZXQgb2Yg
b3B0aW9uYWwgbWVzc2FnZSBwYXJhbWV0ZXJzLiAgDQ0NNC42LjEuIExTUCBSZWNhbGN1bGF0aW9u
IERhdGEgVExWIEZvcm1hdA0NTFNQIFJlY2FsY3VsYXRpb24gRGF0YSBUTFYgaXMgTWFuZGF0b3J5
IFBhcmFtZXRlciBvZiBMU1AgUmVjYWxjdWxhdGlvbiBNZXNzYWdlLiBUaGUgZW5jb2RpbmcgZm9y
IExTUCBSZWNhbGN1bGF0aW9uIERhdGEgVExWIGlzOg0NMCAgICAgICAgICAgICAgICAgICAxICAg
ICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0wIDEgMiAzIDQgNSA2IDcgOCA5
IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNfFV8
RnwgICAgICAgVHlwZSAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgTGVuZ3RoICAgICAgICAg
ICAgIHwNKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSsNfCAgICAgICAgICAgICAgICAgICAgICAgICAgSG9tZSBBZGRyZXNzICAg
ICAgICAgICAgICAgICAgICAgICAgIHwNKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNfCAgICAgICAgICAgICAgICAgICAgICAg
ICBOZXcgRkEgQWRkcmVzcyAgICAgICAgICAgICAgICAgICAgICAgIHwNKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNfCAgICAg
ICAgICAgICAgICAgICAgICBDcm9zc292ZXIgTFNSIEFkZHJlc3MgICAgICAgICAgICAgICAgICAg
IHwNKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSsNDQ1VIGJpdA1Vbmtub3duIFRMViBiaXQuICANDUYgYml0DUZvcndhcmQgdW5r
bm93biBUTFYgYml0LiAgDQ1UeXBlDUlkZW50aWZpZXMgdGhlIHR5cGUgb2YgbWVzc2FnZS4NSW4g
dGhlIGNhc2Ugb2YgTFNQIFJlY2FsY3VsYXRpb24gUmVxdWVzdCBEYXRhIFRMViwgTWVzc2FnZSBU
eXBlIHZhbHVlIGlzIDB4M0YxNy4gSWYgVHlwZSBmaWVsZCB2YWx1ZSBpcyAweDNGMTgsIHRoZW4g
dGhpcyBUTFYgaXMgTFNQIFJlY2FsY3VsYXRpb24gUmVwbHkgRGF0YSBUTFYgaW4gcmVzcG9uc2Ug
dG8gTFNQIEV4dGVuc2lvbiBSZXF1ZXN0IERhdGEgVExWLg0NTGVuZ3RoDVNwZWNpZmllcyB0aGUg
bGVuZ3RoIG9mIHRoZSBWYWx1ZSBmaWVsZCBpbiBvY3RldHMuDSANSG9tZSBBZGRyZXNzDVRoZSBJ
UCBhZGRyZXNzIG9mIHRoZSBtb2JpbGUgbm9kZS4NDU5ldyBGQSBBZGRyZXNzDVRoZSBJUCBhZGRy
ZXNzIG9mIHRoZSBuZXcgRkEuDQ1Dcm9zc292ZXIgTFNSIEFkZHJlc3MNVGhlIElQIGFkZHJlc3Mg
b2YgdGhlIENyb3Nzb3ZlciBMU1IuDQ0NNS4gSUFOQSBDb25zaWRlcmF0aW9ucw0NVGhpcyBkcmFm
dCBkb2VzIG5vdCBjcmVhdGUgYW55IG5ldyBudW1iZXIgc3BhY2VzIGZvciBJQU5BIGFkbWluaXN0
cmF0aW9uLg0NDTYuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQ1UaGlzIGRvY3VtZW50IGRvZXMg
bm90IGhhdmUgYW55IHNlY3VyaXR5IGNvbmNlcm5zLiBUaGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRz
IHVzaW5nIHRoaXMgZG9jdW1lbnQgYXJlIGRlc2NyaWJlZCBpbiB0aGUgcmVmZXJlbmNlZCBkb2N1
bWVudHMuDQ0NNy4gUmVmZXJlbmNlcw0NDA0NOC4gQXV0aG9yJ3MgQWRkcmVzc2VzDQ1KdW4gS3l1
biBDaG9pDUluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0aW9ucyBVbml2ZXJzaXR5IChJQ1UpDTU4
LTQgSHdhIEFobSBEb25nLCBZdXNvbmcsIFRhZWpvbiANS29yZWEgMzA1LTczMg1QaG9uZTogKzgy
LTQyLTg2Ni02MTIyDUVtYWlsOiBqa2Nob2lAaWN1LmFjLmtyDQ1Zb28gS3lvdW5nIExlZQ1FbGVj
dHJvbmljcyBhbmQgVGVsZWNvbW11bmljYXRpb24gUmVzZWFyY2ggSW5zdGl0dXRlIChFVFJJKQ0x
NjEgS2FqdW5nIERvbmcgWXVzb25nLCBUYWVqb24gDUtvcmVhIDMwNS0zMDUNUGhvbmU6ICs4Mi00
Mi04NjAtNjEyMA1FbWFpbDogbGVleWtAZXRyaS5yZS5rcg0NU3VuIEhlZSBZYW5nDUVsZWN0cm9u
aWNzIGFuZCBUZWxlY29tbXVuaWNhdGlvbiBSZXNlYXJjaCBJbnN0aXR1dGUgKEVUUkkpDTE2MSBL
YWp1bmcgRG9uZyBZdXNvbmcsIFRhZWpvbiANS29yZWEgMzA1LTMwNQ1QaG9uZTogKzgyLTQyLTg2
MC01MjMxDUVtYWlsOiBzaHlhbmdAZXRyaS5yZS5rcg0NRXVuIEFoIEtpbQ1FbGVjdHJvbmljcyBh
bmQgVGVsZWNvbW11bmljYXRpb24gUmVzZWFyY2ggSW5zdGl0dXRlIChFVFJJKQ0xNjEgS2FqdW5n
IERvbmcgWXVzb25nLCBUYWVqb24gDUtvcmVhIDMwNS0zMDUNUGhvbmU6ICs4Mi00Mi04NjAtNDgy
MA1FbWFpbDogZWFraW1AZXRyaS5yZS5rcg0NDTkuIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudA0N
IkNvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKGRhdGUpLiBBbGwgUmlnaHRzIFJl
c2VydmVkLiBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNvcGll
ZCBhbmQgZnVybmlzaGVkIHRvIG90aGVycw0sIGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29t
bWVudCBvbiBvciBvdGhlcndpc2UgZXhwbGFpbiBpdCBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVu
dGF0aW9uIG1heSBiZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQgYW5kIGRpc3RyaWJ1dGVk
LCBpbiB3aG9sZSBvciBpbiBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9mIGFueSBraW5kLCBw
cm92aWRlZCB0aGF0IHRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFw
aCBhcmUgaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiBI
b3dldmVyLCB0aGlzICBkb2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkg
d2F5LCBzdWNoIGFzIGJ5IHJlbW92aW5nIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5j
ZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXIgSW50ZXJuZXQgb3JnYW5pemF0aW9u
cywgZXhjZXB0IGFzIG5lZWRlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgZGV2ZWxvcGluZyBJbnRlcm5l
dCBzdGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IgY29weXJpZ2h0cyBk
ZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlIGZvbGxvd2Vk
DSwgb3IgYXMgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0IGludG8gbGFuZ3VhZ2VzIG90aGVyIHRo
YW4gRW5nbGlzaC4NVGhlIGxpbWl0ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBhYm92ZSBhcmUgcGVy
cGV0dWFsIGFuZCB3aWxsIG5vdCBiZSByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9y
IGl0cyBzdWNjZXNzb3JzIG9yIGFzc2lnbnMuDQ0NDQ0NDQ1JbnRlcm5ldCBEcmFmdCAgICAgIERy
YWZ0LWNob2ktbW9iaWxlaXAtbGRwZXh0LTAwLnR4dCAgICAgIERlY2VtYmVyIDIwMDANDQ0NE1BB
R0UgIBUNDQ0NQ2hvaSwgZXQgYWwuCSAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyMDAxICAg
ICAgICAgICAgICAgICAgIFtQYWdlIBMgUEFHRSAUMTkVXQ0NIA1DaG9pIGV0IGFsLgkgICAgICAg
ICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjAwMSAgICAgICAgICAgICAgICAgIFtQYWdlIBMgUEFH
RSAUMRVdDQ0gDQ0NDVsxXSBCcmFkbmVyLCBTLiwgIlRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgUHJv
Y2VzcyAtLSBSZXZpc2lvbiAzIiwgQkNQIDksIFJGQyAyMDI2LCBPY3RvYmVyIDE5OTYuDVsyXSBC
cmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWly
ZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Nw1bM10gQW5kZXJzc29u
IEwuLCBldC4gYWwsIJNMRFAgU3BlY2lmaWNhdGlvbiyUIDxkcmFmdC1pZXRmLW1wbHMtbGRwLTEx
LnR4dD4sIEF1Z3Vlc3QgMjAwMCANWzRdIEd1c3RhZnNzb24gRS4sIGV0IGFsLiwgk01vYmlsZSBJ
UCBSZWdpb25hbCBSZWdpc3RyYXRpb24slCA8ZHJhZnQtaWV0Zi1tb2JpbGVpcC1yZWctdHVubmVs
LTAzLnR4dCwgMTMgSnVseSAyMDAwDVs1XSBQZXJraW5zIEMuLCCTSVAgTW9iaWxpdHkgU3VwcG9y
dCyUIFJGQzIwMDIsIE9jdG9iZXIgMTk5Ng1bNl0gUGVya2lucyBDLiwgk0lQIE1vYmlsaXR5IFN1
cHBvcnQgZm9yIElQdjQslCA8ZHJhZnQtaWV0Zi1tb2JpbGVpcC1yZmMyMDAyLWJpcy0wMi50eHQ+
LCAxMyBKdWx5IDIwMDANWzddIFBlcmtpbnMgQy4sIJNNaW5pbWFsIEVuY2Fwc3VsYXRpb24gd2l0
aGluIElQLJQgUkZDIDIwMDQsIE9jdG9iZXIgMTk5Ng1bOF0gUmVuIFouLCBldCBhbC4sIJNJbnRl
Z3JhdGlvbiBvZiBNb2JpbGUgSVAgYW5kIE1QTFOULCA8ZHJhZnQtemhvbmctbW9iaWxlLWlwLW1w
bHMtMDEudHh0PiwgSnVseSAyMDAwLg1bOV0gSmFtb3Vzc2kgQi4sIGV0IGFsLiwgk0NvbnN0cmFp
bnQtYmFzZWQgTFNQIFNldHVwIHVzaW5nIExEUCyUIDxkcmFmdC1pZXRmLW1wbHMtY3JsLWxkcC0w
NC50eHQ+LCBKdWx5IDIwMDAgDVsxMF0gQXdkdWNoZSBELiBPLiwgZXQgYWwuLCCTUkVWUC1URTog
RXh0ZW5zaW9ucyB0byBSU1ZQIGZvciBMU1AgVHVubmVscyyUIDxkcmFmdC1pZXRmLW1wbHMtcnN2
cC1sc3AtdHVubmVsLTA2LnR4dD4sIEp1bHkgMjAwMA1bMTFdIERlZXJpbmcgUy4sIEVkaXRvciwg
IklDTVAgUm91dGVyIERpc2NvdmVyeSBNZXNzYWdlcyIsIFJGQyAxMjU2LCBTZXB0ZW1iZXIgMTk5
MS4NWzEyXSBHdXN0YWZzc29uIEUuLCBldCBhbC4gIk1vYmlsZSBJUCBSZWdpb25hbCBSZWdpc3Ry
YXRpb24iIHdvcmsgaW4gcHJvZ3Jlc3MsIDxkcmFmdC1pZXRmLW1vYmlsZWlwLXJlZy10dW5uZWwt
MDM+LiBKdWx5IDIwMDANWzEzXSBSaXZlc3QgUi4sICJUaGUgTUQ1IE1lc3NhZ2UtRGlnZXN0IEFs
Z29yaXRobSIsIFJGQyAxMzIxIEFwcmlsIDE5OTINDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAABIEAAATBAAAIAQAADEEAAA1BAAAQAQA
AGIEAABjBAAAcgQAAHQEAAB5BAAAewQAAIgEAACKBAAAjwQAAJEEAACcBAAAngQAAKMEAACkBAAA
swQAALcEAAAbBQAAHAUAAB0FAACeBQAAnwUAALkJAAAeDAAA8QwAAPIMAAD2DAAA/A8AABUQAAAX
EAAAIxAAACUQAAA5EAAAPRAAAFUQAABoEAAAahAAALARAAC7EQAA3xIAAOUSAAA5FAAARRQAAFoX
AABbFwAAURkAAFkZAADYGwAA2hsAAFQiAABcIgAAmSQAAKMkAACxJAAAsyQAAEkmAAB3JgAAgCYA
AIsmAACMJgAAkyYAAJUmAAC0JgAAuyYAALwmAADIJgAAySYAANQnAADVJwAAiykAAJEpAACjKQAA
pCkAAKUpAACqKQAAqykAAK4pAAC1KQAAuSkAALopAADaKQAA3SkAAPcpAAD+KQAA/ykAAAcqAAAV
KgAAFioAACcqAABgKgAA/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD2AP0A8QD9AP0A/QD9AP0A
/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0AAAAJ
A2oAAAAAVQgBDQNqAAAAADBKGABVCAEDbygBAF8ABAAAEwQAACEEAAAiBAAAMQQAADYEAAA3BAAA
YwQAAHIEAABzBAAAdAQAAHkEAAB6BAAAewQAAIgEAACJBAAAigQAAI8EAACQBAAAkQQAAPMAAAAA
AAAAAAAAAADqAAAAAAAAAAAAAAAAp1QAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADqAAAAAAAAAAAA
AAAAp/AAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAApxwAAAAAAAAAAAAAAPMA
AAAAAAAAAAAAAADqAAAAAAAAAAAAAAAApzwAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADqAAAAAAAA
AAAAAAAApxwAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAApzQAAAAAAAAAAAAA
APMAAAAAAAAAAAAAAAAAAAAAAAAAAEIAABYkARckAUlmAQAAAAKWbAAI1jAAAgAAsBtQKAAGsBsA
AAAAAAAAAAAAAAAAAAAAAAagDAAAAAAAAAAAAAAAAAAAAAAU9gNQKBrWCAAAAP8AAAD/G9YIAAAA
/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEKA2wAYfYDbAAJFgADJAIWJAFJZgEAAABh
JAIMFgAPhCIAFiQBSWYBAAAAVkQRAF6EIgAAEwAEAADeDgEA6w8BAOMUAQD9/f0AAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAABAQAAQEDkQQAAJwEAACdBAAAngQAAKMEAACkBAAApQQAALQE
AAC1BAAAtgQAALcEAADeBAAA9wQAABsFAAAcBQAAHQUAADEFAAD2AAAAAAAAAAAAAAAAsxwAAAAA
AAAAAAAAAKcAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAAs0QAAAAAAAAAAAAAAKEAAAAAAAAAAAAA
AAD2AAAAAAAAAAAAAAAAswAAAAAAAAAAAAAAAJ8AAAAAAAAAAAAAAACfAAAAAAAAAAAAAAAAmgAA
AAAAAAAAAAAAAJoAAAAAAAAAAAAAAACaAAAAAAAAAAAAAAAAnwAAAAAAAAAAAAAAAJ8AAAAAAAAA
AAAAAACfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBUAAyQB
YSQBAAEWAAYWABYkAUlmAQAAAAwWAA+EIgAWJAFJZgEAAABWRBEAXoQiAABCAAAWJAEXJAFJZgEA
AAAClmwACNYwAAIAALAbUCgABrAbAAAAAAAAAAAAAAAAAAAAAAAGoAwAAAAAAAAAAAAAAAAAAAAA
FPYDUCga1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABCgNs
AGH2A2wACRYAAyQCFiQBSWYBAAAAYSQCABAxBQAAMgUAAKMFAACkBQAAUgYAAFMGAAAYBwAAGQcA
AOgIAABLCQAArQkAAK4JAACvCQAAuAkAALkJAACECgAAHwwAACAMAAAhDAAALQwAAC4MAAD1DAAA
9gwAAPcMAAAJDQAA9wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA4wAAAAAA
AAAAAAAAAOMAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAOMAAAAAAAAAAAAA
AADjAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA2wAA
AAAAAAAAAAAAANsAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAAzwAAAAAAAAAAAAAAANsAAAAAAAAA
AAAAAADbAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA
4QAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAAAAAACxUAD4SQARGE8AJWRMgA
XoSQAWCE8AIABRUAD4QAAF6EAAAAARUAAAcVAA+EkAFWRMgAXoSQAQALFwAPhJABEYQAAFZEyABe
hJABYIQAAAAHFgAPhJABVkTIAF6EkAEAGAkNAAAKDQAAGg0AAFENAABzDQAAow0AAL8NAADvDQAA
Dg4AACcOAABNDgAAbg4AAJgOAAC7DgAA2w4AAPUOAAATDwAAMw8AAE0PAACADwAAqg8AAMUPAADk
DwAA+w8AABYQAAD5AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADjAAAAAAAA
AAAAAAAA4wAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAA
ANUAAAAAAAAAAAAAAADVAAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAANUAAAAAAAAAAAAAAADVAAAA
AAAAAAAAAAAA1QAAAAAAAAAAAAAAANUAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA1QAAAAAAAAAA
AAAAANUAAAAAAAAAAAAAAADVAAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAANUAAAAAAAAAAAAAAADV
AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANFQAP
hJABEYS3AVZEyABXRLcAXoSQAWCEtwEADRUAD4SWARGEsAFWRMsAV0S0AF6ElgFghLABAAcVAA+E
kAFWRMgAXoSQAQAFFQAPhAAAXoQAAAAYFhAAACQQAAA6EAAAVhAAAFcQAABYEAAAWRAAAFoQAABb
EAAAXBAAAF0QAABeEAAAXxAAAGAQAABhEAAAYhAAAGMQAABkEAAAZRAAAGYQAABnEAAAdxAAAHgQ
AACVEgAAlhIAAB4VAAAfFQAAWxcAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAA
AAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1
AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAA
AAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA
AAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA7wAA
AAAAAAAAAAAAAO8AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAA
AAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFFQAPhAAAXoQA
AAABFQAABxUAD4SQAVZEyABehJABABtbFwAAXBcAAMsZAADMGQAABBsAAAUbAAC7HQAAvB0AADog
AAA7IAAAPCAAAHMgAAB0IAAAliAAAJcgAAAUIQAAFSEAAJIhAAAjIgAAGyMAAPokAACdJQAAniUA
APwlAAD9JQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3
AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAA
AAAAAAAAAPcAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAOEAAAAAAAAAAAAA
AADhAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA0wAA
AAAAAAAAAAAAAO8AAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANFQAPhDUCEYTn
/lZEjgBXRIv/XoQ1AmCE5/4ADRUAD4TFAxGE5/5WRFYBV0SL/16ExQNghOf+AAcVAA+EkAFWRMgA
XoSQAQAFFQAPhAAAXoQAAAABFQAAGP0lAADKJgAAZycAAGgnAABVKQAAVikAAFcpAACHKQAAiCkA
AJcrAACYKwAAAC0AAAEtAABJMAAASjAAANsyAADcMgAAHDMAAFwzAACcMwAA3DMAABw0AABcNAAA
nDQAANw0AAARNQAAUTUAAJE1AADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA
AADxAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAA
AAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAA
AAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA
6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAA
AAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAA
AAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAAAAAAAAARUAAAUVAA+EAABehAAAAA0VAA+ENQIR
hOf+VkSOAFdEi/9ehDUCYITn/gAbYCoAAHQqAAB8KgAArCoAAK0qAACuKgAAvSoAAL4qAADGKgAA
xyoAAMkqAADQKgAA0SoAAO8qAAD6KgAACSsAABYrAAA9KwAAPisAAE4rAABSKwAAlisAAJkrAADD
KwAA0SsAAN0rAADjKwAAAiwAAAMsAAAMLAAADiwAAA8sAAATLAAAKiwAACssAAAuLAAALywAAGIs
AAB2LAAAeSwAAHosAACfLAAArywAAOEsAADiLAAA6iwAAP4sAAD/LAAATDAAAFcwAABYMAAAWTAA
AFwwAABiMAAAYzAAAGswAABvMAAAdjAAAHcwAAB4MAAAezAAAJAwAACjMAAApjAAALAwAAC0MAAA
uTAAAL4wAADCMAAAzzAAAO0wAAAZMQAAGjEAACQxAAAlMQAALDEAADMxAABBMQAARTEAAHQxAACA
MQAAhTEAAIsxAADaMgAA2zIAAHAzAACGMwAAKDQAAC80AABENAAARjQAAG00AABvNAAArTQAALc0
AAC4NAAAujQAALs0AADENAAAAP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A
/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD5/QD9AP0A/QD9AP0A
/QAAAAAABlwIgW8oAQADbygBAGLENAAA6TQAAPA0AADxNAAA9zQAAPg0AAADNQAABDUAAAU1AAAG
NQAACDUAACA1AAAlNQAAKTUAACs1AAA/NQAAQDUAAKA1AACiNQAApDUAAKg1AACpNQAArTUAACQ2
AAAmNgAAKzYAAC42AABRNgAAWjYAAGQ2AABlNgAAazYAAHA2AACRNgAAljYAAJ42AACgNgAAoTYA
AKQ2AAClNgAApzYAAF83AAATOAAASDgAAGw4AABxOAAAjTgAAJI4AADPOAAA0DgAAJw5AACdOQAA
uzkAAMI5AADaOQAA7DkAAO85AAAEOgAANDoAADU6AAB6OgAAezoAAHw6AACvOgAA8DoAAPE6AAAw
OwAAMTsAAHU7AAB2OwAAujsAALs7AADTOwAA1jsAADg8AAA5PAAAQjwAAEg8AACgPAAAoTwAAOY8
AADnPAAAKj0AACs9AABpPQAAaz0AAK49AACvPQAA/z0AAAA+AAAtPgAAMj4AAEM+AABEPgAAnD4A
AKI+AABEPwAART8AAH4/AAD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A
/fn9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9
AAAAAAAGXAiBbygBAANvKAEAYpE1AADRNQAAETYAAFE2AACRNgAAyzYAAAs3AAAnNwAAQzcAAF83
AABgNwAAdzcAAJM3AACiNwAAtDcAAMQ3AADTNwAA1DcAABM4AAAzOAAANDgAADU4AAB7OgAAfDoA
AGo9AABrPQAARj8AAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA
AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA
AAAA+QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEA
AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAD5AAAAAAAA
AAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAA
AOYAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARUAAAgVAAMkAQ+EAABehAAAYSQBAAcVAA+EWAJWRCwB
XoRYAgAFFQAPhAAAXoQAAAAaRj8AAEc/AAACQQAAA0EAAD1GAAA+RgAAHkcAAB9HAAAwRwAAQUcA
AG9HAABwRwAAcUcAAKBHAADWRwAAFkgAAFZIAACWSAAA1kgAABZJAABWSQAAlkkAAMtJAAALSgAA
S0oAAItKAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8A
AAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADjAAAAAAAA
AAAAAAAA1wAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAA
AOMAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADjAAAA
AAAAAAAAAAAA4wAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAAAAALFQAPhAAA
EYSgBVdEWAJehAAAYISgBQAFFQAPhAAAXoQAAAAFFQAPhJABXoSQAQANFQAPhJABEYTgAVZEyABX
RMgAXoSQAWCE4AEAARUAABl+PwAAfz8AAK0/AACuPwAAxT8AAMY/AAAJQAAACkAAAE1AAABOQAAA
k0AAAJRAAADYQAAA2UAAAAFBAAADQQAAEkEAABZBAABJQQAASkEAAIxBAACNQQAA0EEAANFBAABL
QgAAUEIAAN9CAADgQgAAF0MAAB1DAAAjQwAAJEMAAExDAABiQwAAdUMAAHZDAACGQwAAjEMAAPZD
AAD3QwAANkQAADdEAAB7RAAAfEQAAIxEAACNRAAAxEQAANZEAADXRAAAr0UAALBFAADdRgAA4EYA
AIVHAACbRwAAJUgAACZIAABoSQAAakkAAGtJAABxSQAAckkAAHRJAAB1SQAAe0kAAHxJAAB+SQAA
o0kAAKpJAACrSQAArUkAAK5JAACxSQAAskkAAL1JAAC+SQAAv0kAAMBJAADCSQAA2kkAAN9JAADj
SQAA5UkAAPlJAAD6SQAAWkoAAFxKAABeSgAAYkoAAGNKAABnSgAA3koAAOBKAADlSgAA6EoAAAtL
AAAUSwAAJksAACpLAABLSwAAUEsAAP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9
AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A
/QD9AP0A/QAAAANvKAEAZItKAADLSgAAC0sAAEtLAACFSwAAxUsAAOFLAAD9SwAAGUwAABpMAABZ
TAAAf0wAAIBMAACBTAAA3E0AAN1NAAAMTwAADU8AAElPAABnTwAAwk8AAMNPAAD+UAAA/1AAAJNT
AACUUwAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA
APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA
AAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA6gAAAAAAAAAA
AAAAAOgAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADa
AAAAAAAAAAAAAAAA2gAAAAAAAAAAAAAAANoAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA6AAAAAAA
AAAAAAAAAOgAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAAAAAAAAAAAADRUA
D4QzCBGEDftWRKABV0Tw/V6EMwhghA37AAEVAAAFFQAPhJABXoSQAQAIFQADJAEPhAAAXoQAAGEk
AQAFFQAPhAAAXoQAAAAZUEsAAFhLAABaSwAAW0sAAF5LAABfSwAAYUsAABlMAABZTAAAfkwAAH9M
AAAlUQAAL1EAAKVRAACpUQAAAlQAAANUAABCVAAAQ1QAAFRUAABcVAAAYVQAAG1UAACDVAAAhFQA
AMhXAADTVwAAM1gAADlYAABRWAAAXVgAAE9ZAABRWQAAbFkAAG5ZAACIWQAAVloAAGNaAADIWgAA
1loAAOdaAAD9WgAA/loAAA1cAAAGXgAAEV4AAHleAAC8XgAAvV4AAMVeAADGXgAAGV8AABpfAACa
XwAAnV8AAMhfAADJXwAAAGAAAAJgAAAfYAAAIGAAAExgAABSYAAA9mAAAPdgAAD4YAAA+mAAABJh
AAAUYQAAFWEAABthAAA2YQAAUGEAAFNhAABVYQAAVmEAAGxhAABtYQAAeGEAAHphAACGYQAAiWEA
AJFhAACUYQAAuWEAALthAADMYQAA/QD9AP0A/fn9+f0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP31
8vXy9fL17P0A/ePZ49nj2ePZ49nj2ePZ49nj2f3j2ePZ49nj2ePZ49nj2ePZ49nj2eMTQ0oYAE9K
AwBRSgMAXkoDAG8oARBDShgAT0oDAFFKAwBeSgMAAAtQSgQAXkoDAG8oAQReSgMAAAdeSgMAbygB
BlwIgW8oAQADbygBAFaUUwAAJlYAACdWAAAWVwAAF1cAAGxXAABtVwAAblcAAIpXAACLVwAAjVgA
AI5YAAD0WAAA9VgAAPZYAAAmWQAAJ1kAAEZZAABHWQAASFkAAElZAABKWQAAS1kAAExZAABNWQAA
TlkAAG1ZAABuWQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAO8AAAAAAAAA
AAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA
9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAA
AAAAAAAAAAD3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcVAA+EkAFWRMgAXoSQAQAFFQAP
hAAAXoQAAAABFQAAG25ZAACHWQAAiFkAAP5aAAD/WgAADVwAAA5cAAAPXAAANVwAADZcAACJXAAA
ilwAALdcAADiXAAAKl0AACtdAAD0XQAA9V0AAFVeAABWXgAAV14AAHheAAB5XgAA92AAAPhgAAD5
AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAA
AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA
AADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA4QAA
AAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA
2QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcaAA+EkAFW
RMgAXoSQAQANFQAPhOEDEYSf/lZEQAFXRG3/XoThA2CEn/4ABxUAD4SQAVZEyABehJABAAEVAAAF
FQAPhAAAXoQAAAAY+GAAADlhAAB6YQAAu2EAAPxhAAA9YgAAfmIAAL9iAAAAYwAAQWMAAIJjAADD
YwAABGQAAEVkAACGZAAAx2QAAAhlAABJZQAAimUAAMtlAAAMZgAATWYAAI5mAADPZgAAEGcAABFn
AABLZwAATGcAAPMAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAA
AAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA
8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAA
AAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAA
AAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEA
AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADsAAAAAAAA
AAAAAAAA8QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEGgADJAFhJAEAARoAAAsaAA+E4AERhCD+V0Q4
/16E4AFghCD+ABvMYQAA/GEAABliAAAaYgAAO2IAAD1iAAB8YgAAfmIAAJNiAACcYgAAvWIAAL9i
AADcYgAA3WIAAP5iAAAAYwAAF2MAABpjAAAcYwAAHWMAADNjAAA0YwAAP2MAAEFjAAB0YwAAdWMA
AIBjAACCYwAAwWMAAMNjAAAAZAAAAmQAACNkAABCZAAAQ2QAAEVkAABkZAAAZWQAAINkAACEZAAA
tmQAALtkAADCZAAAxWQAAMZkAADHZAAA2WQAAN5kAAD6ZAAA+2QAAAZlAAAIZQAAH2UAACJlAAAk
ZQAAJWUAACdlAABJZQAAYGUAAGNlAABlZQAAZmUAAGhlAACJZQAAqWUAAKplAADIZQAAyWUAAABm
AAAMZgAAI2YAACZmAAAoZgAAKWYAAD9mAABAZgAAS2YAAE1mAABsZgAAbWYAAIlmAACKZgAAtGYA
ALtmAADDZgAAz2YAAOZmAADpZgAA62YAAOxmAAACZwAAA2cAAA5nAABMZwAA9ez17PXs9ez17PXs
9ez17PXs9ez17PXs9ez17PXs9ez17PXs9ez17PXs9ez17PXs9ez17PXs9ez17PXs9ez17PXs9ez1
7PXs9ez17PXs9ez17PXs9ez17PXs9ez1AAAAEENKGABPSgMAUUoDAF5KAwAAE0NKGABPSgMAUUoD
AF5KAwBvKAEAXUxnAACXZwAAmGcAAMpnAADPZwAA2mcAAOFnAABjaAAAZGgAAMJoAADDaAAAR2oA
AEhqAAAVawAAFmsAAINrAACEawAAr2sAANtrAADjawAAGmwAABtsAABLbAAATGwAAE1sAABObAAA
j2wAAJBsAADKbAAAy2wAAOBsAADhbAAAIW0AACJtAABabQAAW20AAGVtAACCbQAAg20AAIVtAACG
bQAAiW0AAIptAACNbQAAmG0AAJltAAC0bQAAuG0AALttAAC+bQAAym0AAO9tAAD6bQAA+20AAPxt
AAAXbgAAHW4AACBuAAArbgAAUW4AAFxuAACCbgAAjW4AAI5uAACPbgAArW4AALBuAACybgAAvm4A
AL9uAADabgAA3m4AAOFuAADjbgAAIm8AAFxvAABdbwAAoG8AAKJvAAC/bwAAwG8AAOdvAADobwAA
LHAAAC1wAAA6cAAAO3AAAG5wAABvcAAAjnAAAJBwAACzcAAAtHAAAPlwAAD37fft9+337fft9+33
7fft9+vt9+337fft9+337fft9+336+337fft9+337fft9+337fft9+337fft9+337fft9+337fft
9+337fft9+337fft9+337fft9+337fcAA28oARNDShgAT0oDAFFKAwBeSgMAbygBEENKGABPSgMA
UUoDAF5KAwBdTGcAAHxpAAB9aQAAr2sAALBrAACxawAA22sAANxrAABabQAAW20AAI1tAAC+bQAA
720AACBuAABRbgAAgm4AALNuAADkbgAA5W4AACJvAAAjbwAAEXEAABJxAAATcQAANnEAADdxAAB2
cgAAd3IAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA
AADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA8QAA
AAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAA
AAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA
7wAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPEAAAAA
AAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAD3AAAAAAAAAAAA
AAAA7wAAAAAAAAAAAAAAAAAAAAAAAAQaAAMkAWEkAQABGgAABRUAD4QAAF6EAAAABxoAD4SQAVZE
yABehJABABv5cAAA+nAAABFxAAA3cQAA5HEAAOlxAADtcQAA93EAAAlyAAAicgAAJnIAADZyAAA4
cgAAd3IAAIRyAACgcgAAqHIAAKpyAAC4cgAAz3IAANFyAADdcgAA63IAAAtzAAANcwAAEHMAAB5z
AABDcwAAUXMAAHZzAACEcwAAknMAAJpzAACpcwAAt3MAANxzAAAmdAAAMXQAADl0AAA7dAAAk3QA
AJR0AACbdAAAxXQAAM50AADhdAAA43QAAOl0AADvdAAACXUAANB2AADRdgAA1HYAANZ2AAAheAAA
JHgAAMN5AADGeQAAN3wAAFp8AAByfAAAenwAAIF8AACNfAAAjnwAAJt8AACgfAAAsXwAAMF8AADF
fAAAxnwAAMt8AADRfAAA53wAAOt8AADufAAABn0AAA99AAATfQAAGX0AAC59AAA3fQAAQn0AAEp9
AABOfQAAUH0AAFF9AABUfQAAWX0AAHV9AAB2fQAAzH0AAM19AAD17Or17PXs9ez17PXs9ez17PXs
9ez17PXs9ez17PXs9ez17PXs9ez17PXs9ez17PXs9ez17PXs9ez16gDqAOoA6gDqAOoA6gDqAOoA
6gDqAOoA6gDqAOoA6gDqAAAAAAADbygBEENKGABPSgMAUUoDAF5KAwAAE0NKGABPSgMAUUoDAF5K
AwBvKAEAXHdyAACrcgAA3nIAABFzAABEcwAAd3MAAKpzAADdcwAA3nMAABp0AAAbdAAACnUAAAt1
AABCdgAAQ3YAAER2AACGdgAAyHYAAAp3AABMdwAAjncAANB3AAASeAAAVHgAAJZ4AADYeAAAGnkA
AFx5AACeeQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAA
AAAAAAAAAPAAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAHGgAPhJABVkTIAF6EkAEABBoAAyQBYSQB
AAEaAAAcnnkAAOB5AAAiegAAZHoAAKZ6AADoegAAKnsAAGx7AACuewAA8HsAAPF7AAA3fAAAOHwA
ADl8AABZfAAAWnwAAGl+AABrfgAAl34AAMl+AAAGfwAAQ38AAIB/AAC4fwAA8H8AACiAAABggAAA
mIAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA
AAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAA
AAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAA
AAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA
9wAAAAAAAAAAAAAAAAAAAAAAAAAACxUAD4SrARGE//9WRNUAXoSrAWCE//8ABRUAD4QAAF6EAAAA
ARoAABvNfQAA0X0AANx9AADefQAA730AAPZ9AAAOfgAAEn4AAB1+AAAgfgAAMX4AADd+AABQfgAA
UX4AAGN+AABnfgAAaH4AAJd+AAClfgAAvn4AAMZ+AADWfgAA134AABN/AAAcfwAAHX8AACd/AAAp
fwAAKn8AACt/AAAvfwAAMH8AADR/AAA9fwAATX8AAE9/AABSfwAAU38AAFR/AABVfwAAWX8AAFp/
AABbfwAAXH8AAG9/AABwfwAAd38AAHt/AACBfwAAjn8AAJN/AACVfwAAmH8AAPB/AAD4fwAA+X8A
AP1/AAD/fwAAAYAAAAKAAAAFgAAAKIAAAC+AAAAzgAAANIAAADqAAAA7gAAAq4AAAKyAAACPhwAA
w4cAAOGIAADniAAAy4kAANWJAAD6iQAABooAAAiKAAAzigAATIsAAFqLAAB0iwAAeosAAIiLAACJ
iwAAxIsAAM2LAADOiwAA2IsAAOCLAADkiwAA7YsAAP2LAAD/iwAAAowAAAOMAAAEjAAABYwAAAmM
AAAKjAAAC4wAAP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9
AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QAAAANv
KAEAZJiAAADVgAAAEoEAAE+BAABigQAAY4EAAImBAACKgQAAi4EAAMyBAAANggAAToIAAI+CAADQ
ggAAEYMAAFKDAACTgwAA1IMAABWEAABWhAAAl4QAANiEAAAZhQAAWoUAAJuFAADchQAAHYYAAPkA
AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADwAAAAAAAA
AAAAAAAA8AAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA
APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA
AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA
AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5
AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAALFQAPhKkBEYT//1ZE1ABehKkBYIT//wAIFQADJAEPhAAAXoQAAGEkAQAFFQAPhAAAXoQA
AAAaHYYAAF6GAACfhgAAoYYAAM6GAADPhgAA0IYAAAmHAAAKhwAAVYcAAIqHAADZhwAATogAAKuI
AADoiAAA6YgAAOqIAAABiQAAAokAALKJAAChigAAoooAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA
AAAA+QAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADeAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAANIA
AAAAAAAAAAAAAADSAAAAAAAAAAAAAAAAxAAAAAAAAAAAAAAAAMQAAAAAAAAAAAAAAADEAAAAAAAA
AAAAAAAAxAAAAAAAAAAAAAAAAMQAAAAAAAAAAAAAAADEAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA
APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAAC8AAAA
AAAAAAAAAAAAvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHFQAPhKoBVkTVAF6EqgEADRUA
D4ThAxGEzf5WRFcBV0SA/16E4QNghM3+AAsVAA+EVAMRhFb+VkTVAF6EVANghFb+AAsVAA+EqQER
hP//VkTUAF6EqQFghP//AA4VAAMkAQ+EqQERhP//VkTUAF6EqQFghP//YSQBAAUVAA+EAABehAAA
ABWiigAA0YoAANKKAAAHiwAAJ4sAAEqLAABLiwAATIsAAHuLAAC3iwAA84sAAC+MAABmjAAAnYwA
ANSMAAALjQAAQo0AAH6NAAC6jQAA9o0AAAmOAAALjgAANY4AADaOAAA3jgAA9wAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADpAAAA
AAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAA
AAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADp
AAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAA
AAAAAAAAAOkAAAAAAAAAAAAAAADfAAAAAAAAAAAAAAAA1gAAAAAAAAAAAAAAANYAAAAAAAAAAAAA
AADpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIFQADJAEPhAAAXoQAAGEkAQAJFQANxgUA
AXEWAA+EAABehAAAAAUVAA+EAABehAAAAAcVAA+EcgJWRDkBXoRyAgAHFQAPhKoBVkTVAF6EqgEA
GAuMAAAMjAAAE4wAABWMAAAejAAAH4wAACaMAAAqjAAAMIwAAD2MAABCjAAARIwAAEeMAACdjAAA
pYwAAKaMAACqjAAArIwAAK6MAACvjAAAsowAANSMAADbjAAA34wAAOCMAADmjAAA54wAAFWNAABW
jQAACY4AAAqOAACamQAAnZkAANqZAAAhmgAAIpoAAE2aAADMmgAADZsAAA6bAAA9mwAAPpsAAE+b
AABQmwAAWZsAAFqbAABdmwAAX5sAAJCbAACRmwAAwZsAAMWbAADJmwAAypsAABicAAAZnAAAhJ0A
AIedAACrnQAAxp0AAE2eAABOngAAK58AACyfAAA6nwAAO58AAD+fAABAnwAAoZ8AAKKfAAARoAAA
EqAAAFWgAABWoAAAmqAAAJugAAA9owAAPqMAAKmjAACqowAAlqQAAJekAADCpAAAxqQAAMqkAADL
pAAAp6UAAKilAAC8pQAAvaUAAMelAADIpQAAyqUAANKlAADepQAA36UAAOGlAADppQAA8qUAAHCm
AACzpgAA/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9
AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AAAAA28oAQBk
N44AADiOAAA5jgAAfI4AAL2OAAD/jgAAQY8AAIOPAADFjwAAB5AAAEmQAACLkAAAzZAAAA+RAABR
kQAAk5EAANWRAAAXkgAAWZIAAJuSAADdkgAAH5MAAGGTAACjkwAA5ZMAACeUAAD5AAAAAAAAAAAA
AAAA7QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA
AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA
AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA
APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADZAAAA
AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA
AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAACxUAD4TwABGEEP9XRJz/XoTwAGCE
EP8ABxUAD4SOAFZERwBehI4AAAsVAA+EqQERhP//VkTUAF6EqQFghP//AAUVAA+EAABehAAAABkn
lAAAaZQAAKuUAADtlAAAL5UAAHGVAACzlQAA9ZUAADeWAAB5lgAAu5YAAP2WAAA/lwAAgZcAAMOX
AAAFmAAAR5gAAImYAACKmAAAvJgAAL2YAAC+mAAA/JgAAP2YAABcmQAA2JkAAPkAAAAAAAAAAAAA
AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA
AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA
+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPAAAAAA
AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAAD5AAAAAAAAAAAA
AAAA2gAAAAAAAAAAAAAAANoAAAAAAAAAAAAAAAAAAAAAAAAAAA0VAA+E4QMRhM3+VkRXAVdEgP9e
hOEDYITN/gAHFQAPhJABVkTIAF6EkAEACBUAAyQBD4QAAF6EAABhJAEABRUAD4QAAF6EAAAAGdiZ
AABOmgAAhJoAAIWaAACGmgAAh5oAAIiaAACJmgAAipoAAIuaAACMmgAAqpoAAKuaAADLmgAAzJoA
AMKbAADDmwAAxJsAANSbAADVmwAALJwAAC2cAABrnAAAq5wAAO2cAAAvnQAAxp0AAPEAAAAAAAAA
AAAAAADxAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA
6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAA
AAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAA
AAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA3wAAAAAAAAAAAAAAAOkA
AAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAA
AAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAAAAkVAA3GBQABAAAA
D4QAAF6EAAAAARUAAAUVAA+EAABehAAAAA0VAA+E4QMRhM3+VkRXAVdEgP9ehOEDYITN/gAaxp0A
AAieAAAqngAATJ4AAE2eAABOngAAVp4AAIueAACMngAAmJ4AANyeAADdngAA7J4AADifAAA5nwAA
Op8AAFyfAABdnwAAy58AAMyfAACvoAAAsKAAAO6gAAAuoQAAcKEAALKhAAD0oQAANqIAAPkAAAAA
AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA
AAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcA
AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAA
AAAAAAAA9wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA
AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAkVAA3GBQABAAAAD4QAAF6EAAAAARUAAAUVAA+EAABehAAAABs2ogAA
eKIAALqiAAD8ogAAPqMAAGCjAACCowAAg6MAAImjAACtowAArqMAALSjAADgowAA4aMAAOajAAAY
pAAAGaQAACCkAABTpAAAVKQAAFqkAADDpAAAxKQAAMWkAAD2pAAA96QAAH+lAAD5AAAAAAAAAAAA
AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA
AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAA
AAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAA
AO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAA
AAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAA
AAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAABxUAD4SqAVZE1QBehKoBAAcVAA+EHAFWRI4AXoQcAQABFQAABRUAD4QAAF6EAAAAGn+lAACA
pQAAoqUAAL2lAADZpQAA86UAABGmAAAtpgAAT6YAAG+mAABwpgAAcaYAAN6nAADfpwAACqgAADOo
AABfqAAAjqgAAL2oAADqqAAAHakAAE6pAABPqQAAUKkAAGqpAABrqQAApKoAAKWqAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAA
APMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADt
AAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAA
AAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAFFQAPhAAAXoQAAAAJFQARhNACVkTYAFdELAFghNACAAEVAAAbs6YAALSm
AAAppwAAKqcAAOmnAADqpwAAFKgAABWoAAA8qAAAPqgAAECoAABIqAAAZKgAAGeoAABrqAAAbKgA
AI2oAABrqQAAn6kAAKCpAACrqQAArKkAAPCpAADxqQAAM6oAADSqAACkqgAAp6oAAM6rAADPqwAA
IK4AACGuAACkrgAApa4AAIWxAACIsQAAi7EAAIyxAACNsQAAj7EAACyyAAAtsgAAibMAAIqzAADq
tgAA67YAAF23AABetwAAj7cAAJC3AACUtwAAlbcAAMq3AADLtwAA/bcAAP63AAAuuAAAL7gAAEu4
AABMuAAAj7gAAJC4AABguQAAYbkAAGa5AABpuQAAarkAAGu5AABsuQAAbrkAAMS5AADFuQAA+7kA
APy5AAA+ugAAP7oAAEK7AABDuwAAVLsAAFW7AABXuwAAWbsAAFq7AABbuwAAXLsAAF27AABeuwAA
X7sAAGC7AABiuwAAhLsAAIW7AACMvgAAjb4AAFC/AABRvwAAWMAAAFnAAAA1wgAAOMIAADnCAAD9
AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A
/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0AAAADbygBAGSlqgAApqoA
ANOqAADXqgAADasAAA+rAABNqwAAjasAAM+rAAARrAAAU6wAAJWsAADXrAAAGa0AAFutAACdrQAA
360AACGuAABjrgAApa4AAOeuAAAprwAAa68AAK2vAADvrwAA8K8AAPavAAANsAAADrAAAP0AAAAA
AAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcA
AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAA
AAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAA
AAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFFQAPhAAAXoQAAAABFQAAHA6wAAAbsAAA
OrAAADuwAABKsAAAh7AAALawAAC3sAAAwrAAAPCwAADxsAAABrEAADqxAAA7sQAAT7EAAIWxAACG
sQAAh7EAALWxAAC2sQAARbIAAEayAACEsgAAxLIAAAazAABIswAAirMAAMyzAAAOtAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAA
AAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA
AAAA9wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUVAA+EAABehAAAAAEVAAAcDrQAAFC0AACS
tAAA1LQAABa1AABYtQAAmrUAANy1AAAetgAAYLYAAKK2AACjtgAAqbYAALy2AAC9tgAAw7YAAN62
AADftgAA5LYAAOu2AADstgAA87YAACa3AAAntwAANbcAAGK3AABjtwAAabcAAJS3AAD5AAAAAAAA
AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA
APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA
AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAA
AAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3
AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAA
AAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA
AAD3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARUAAAUVAA+EAABehAAAAByUtwAAlbcAAJu3
AADOtwAAz7cAANW3AAABuAAAArgAAAq4AAAyuAAAM7gAADq4AABPuAAAULgAAFi4AAB0uAAAdbgA
AH64AACTuAAAlLgAAKG4AADEuAAAxbgAANC4AAAAuQAAAbkAABG5AAA/uQAAQLkAAE+5AAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFQAAHU+5AABmuQAAZ7kA
AGi5AACCuQAAg7kAAFi7AABZuwAAWrsAAIW7AACGuwAAt7sAALu7AAD5uwAAObwAAHu8AAC9vAAA
/7wAAEG9AACDvQAAxb0AAAe+AABJvgAAi74AAM2+AAAPvwAAUb8AAP0AAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADj
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAA
AAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA
AAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAA
AAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAAAAAAAAAAAAAADRUAD4SqARGEBQBW
RNUAV0QCAF6EqgFghAUAAAUVAA3GBQABNQcAAAUVAA+EAABehAAAAAEVAAAaUb8AAJO/AADVvwAA
F8AAAFnAAACbwAAAnMAAAKLAAAC5wAAAusAAAMfAAADmwAAA58AAAPbAAABmwQAAZ8EAAHLBAACg
wQAAocEAALbBAADqwQAA68EAAP/BAAA1wgAANsIAADfCAABiwgAAY8IAAJjCAAD5AAAAAAAAAAAA
AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcA
AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAA
AAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAA
AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAA
AAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARUAAAUVAA+EAABehAAAABw5wgAAOsIAAD3CAAA+
wgAAVcMAAFfDAACXwwAAmcMAANnDAADbwwAAG8QAAB3EAABdxAAAX8QAAJ/EAAChxAAA4sQAAOXE
AAAjxQAAJcUAAGXFAABnxQAAaMUAAGnFAACnxQAAqcUAAOnFAADrxQAA7MUAAO3FAADuxQAAL8YA
AG3GAABwxgAAucYAALrGAABgxwAAYccAAPLHAADzxwAAsMgAALLIAAD/yAAAAMkAAAPJAAA5yQAA
B8oAADPKAAA1ygAAZMoAAGbKAACEygAAhcoAAI/KAACSygAAv8oAAMfKAADoygAA6coAADTLAABD
ywAAY8sAAGXLAADUywAA1csAANvLAADdywAA4ssAAOfLAADoywAA/ssAAP/LAAC6zAAAvMwAAP3M
AAD/zAAAP80AAEHNAACBzQAAg80AAMPNAADFzQAABc4AAAfOAABHzgAASc4AAInOAACLzgAAy84A
AM3OAAANzwAAD88AAE/PAAD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A
/QD9AP3z6vPq8+rz6vPq8+rz6vPq8+rz6vPq8/3q8+rz6vPq8+rz6vPq8+rz6vPq8+rz6gAAAAAQ
Q0oYAE9KAwBRSgMAXkoDAAATQ0oYAE9KAwBRSgMAXkoDAG8oAQNvKAEAXJjCAACZwgAA18IAABfD
AABZwwAAm8MAAN3DAAAfxAAAYcQAAKPEAADlxAAAJ8UAAGnFAACrxQAA7cUAAC/GAABxxgAAcsYA
AHjGAACLxgAAjMYAAJLGAACtxgAArsYAALPGAAC6xgAAu8YAAMLGAAD1xgAA/QAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAA
AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAA
AAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3
AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAA
AAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA
AADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAA
AAAAAAAAAAAAAAAAAAUVAA+EqgFehKoBAAUVAA+EAABehAAAAAEVAAAc9cYAAPbGAAAAxwAARccA
AEbHAABPxwAAZMcAAGXHAAByxwAAlccAAJbHAAChxwAA0ccAANLHAADhxwAA9scAAPfHAAA3yAAA
UMgAAFHIAABpyAAAscgAALLIAAADyQAABMkAAAXJAAA4yQAAOckAAPkAAAAAAAAAAAAAAAD5AAAA
AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA
AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5
AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA
AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA
AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA8QAA
AAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAABRUAD4QAAF6EAAAAARUAAAUVAA+EqgFehKoBABs5yQAABsoAAAfKAAAYygAA
GcoAAEPKAACFygAAx8oAAAnLAAASywAAQ8sAAETLAABkywAAZcsAAITLAACMywAA1csAANvLAADc
ywAA3csAAP7LAAD/ywAAPcwAAH3MAAC/zAAAAc0AAEPNAACFzQAA9wAAAAAAAAAAAAAAAPUAAAAA
AAAAAAAAAAD3AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAAD1AAAAAAAAAAAA
AAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUA
AAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAA
AAAAAAAA9QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAA
AAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAABxoAEYRwCFdEhANghHAIAAEaAAAHGgAPhJABVkTIAF6EkAEAG4XNAADHzQAACc4AAEvOAACN
zgAAz84AABHPAABTzwAAlc8AANfPAADYzwAA6c8AAOrPAAAI0AAACdAAAEzQAABN0AAAf9AAAIDQ
AADG0AAA89AAAPTQAAAm0QAAJ9EAAGrRAACw0QAAsdEAAOjRAAD40QAA+dEAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEaAAAdT88AAFHPAACRzwAAk88AANPP
AADVzwAAB9AAAAjQAAAl0AAAS9AAAHrQAAB80AAAIdEAACPRAADN0QAA2dEAANrRAAD40QAAJtIA
ACjSAAAq0gAAOtIAAD3SAABC0gAAR9IAAEjSAAAa0wAAHNMAAFzTAABe0wAAntMAAKDTAADg0wAA
4tMAACLUAAAk1AAAdNQAAJrUAAC31AAAuNQAAMnUAADL1AAAC9UAAAzVAAA51QAAQdUAAELVAAA1
1wAAOdcAADrXAAA71wAAPdcAAD7XAABO2AAAUNgAAJDYAACS2AAA0tgAANTYAAAU2QAAFtkAAFbZ
AABY2QAAmNkAAJzZAADa2QAA3NkAABzaAAAe2gAAXtoAAGDaAACg2gAAotoAAOLaAADk2gAA5doA
AObaAAAk2wAAJtsAACfbAAAo2wAAZtsAAGjbAACo2wAAqtsAAOrbAADs2wAALNwAAC7cAABu3AAA
cNwAAAreAAAL3gAA9ez17PXs9ez17PXs9ez17PXs9ez16uz16uz17PXs9ez17PXs9ez17PXsAOoA
6gDqAOoA6gDqAOoA6gDqAOoA6gDqAOoA6gDqAOoA6gDqAOoA6gDqAOoA6gDqAOoAAAAAA28oARBD
ShgAT0oDAFFKAwBeSgMAABNDShgAT0oDAFFKAwBeSgMAbygBAFz50QAAK9IAADvSAAA80gAAPdIA
AF3SAABe0gAAnNIAANzSAAAe0wAAYNMAAKLTAADk0wAAJtQAACfUAAA31AAAONQAAFfUAABY1AAA
m9QAAJzUAADO1AAAz9QAAAzVAAAN1QAADtUAADjVAAA51QAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAA
AAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAcaAA+EkAFWRMgAXoSQAQAFFQAPhAAAXoQAAAABGgAAGznVAAA21wAAN9cAADjXAABd1wAA
X9cAAJDXAACS1wAA0NcAABDYAABS2AAAlNgAANbYAAAY2QAAWtkAAJzZAADe2QAAINoAAGLaAACk
2gAA5toAACjbAABq2wAArNsAAO7bAAAw3AAActwAAHPcAAD3AAAAAAAAAAAAAAAA8QAAAAAAAAAA
AAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADv
AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAA
AAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA
AADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAA
AAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAA
AAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAARUAAAUVAA+EAABehAAAAAcVAA+EkAFWRMgAXoSQAQAbc9wAAHncAACQ3AAAkdwAAJ7cAAC9
3AAAvtwAAM3cAAAK3QAAOd0AADrdAABF3QAAc90AAHTdAACJ3QAAvd0AAL7dAADS3QAACN4AAAne
AAAK3gAAMN4AADHeAACo3gAAqd4AAOfeAAAn3wAAad8AAKvfAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAABRUAD4QAAF6EAAAAARUAABwL3gAADN4AAA3eAABl3wAAZ98AAKff
AACp3wAA6d8AAOvfAAAr4AAALeAAAG3gAABv4AAAP+EAAEDhAABB4QAAQuEAAEPhAABE4QAARuEA
AEfhAABd4gAAX+IAAJ/iAACh4gAA4eIAAOPiAAAj4wAAJeMAAGXjAABn4wAAp+MAAKnjAADp4wAA
6+MAAOzjAADt4wAAK+QAAC3kAAAu5AAAL+QAAG3kAABv5AAAr+QAALHkAADx5AAA8+QAADPlAAA1
5QAAdeUAAHflAAB45QAAeeUAALflAAC55QAA+eUAAPvlAAA75gAAPeYAAD7mAAA/5gAAfeYAAH/m
AAAZ6AAAGugAABvoAAAc6AAAgOkAAILpAADC6QAAxOkAAMXpAADG6QAABOoAAAbqAAAH6gAACOoA
AEbqAABI6gAAiOoAAIrqAADK6gAAzOoAAAzrAAAO6wAAD+sAABDrAABO6wAAUOsAAJDrAACS6wAA
rusAAK/rAABx7AAAcuwAAPvsAAAZ7QAALu0AADvtAAAG7gAACO4AAAD9AP0A/QD9AP0A/QD9AP0A
/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9
AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0AAANvKAEAZKvfAADt3wAAL+AAAHHgAABy4AAAeOAA
AIvgAACM4AAAkuAAAK3gAACu4AAAs+AAANLgAADT4AAA2uAAAA3hAAAP4QAAHOEAAD/hAABA4QAA
QeEAAGnhAABr4QAAn+EAAKHhAADf4QAAH+IAAGHiAACj4gAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA
9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAA
AAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA
AAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcA
AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAA
AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAEVAAAFFQAPhAAAXoQAAAAco+IAAOXiAAAn4wAAaeMAAKvjAADt4wAA
L+QAAHHkAACz5AAA9eQAADflAAB55QAAu+UAAP3lAAA/5gAAgeYAAILmAACI5gAAn+YAAKDmAACt
5gAAzOYAAM3mAADc5gAAGecAAEjnAABJ5wAAVOcAAILnAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA
AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5
AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA
AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA
AAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAA
AAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAA
AAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAARUAAAUVAA+EAABehAAAAByC5wAAg+cAAJjnAADM5wAAzecAAOHnAAAX
6AAAGOgAABnoAABC6AAAQ+gAAMPoAADE6AAAAukAAELpAACE6QAAxukAAAjqAABK6gAAjOoAAM7q
AAAQ6wAAUusAAJTrAACV6wAAm+sAAK7rAACv6wAAtesAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAA
AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAFFQAPhAAAXoQAAAABFQAAHLXrAADQ6wAA0esAANbrAAD16wAA9usAAP3r
AAAw7AAAMewAADrsAACK7AAAjOwAAJnsAAC87AAAvewAAM3sAAD77AAA/OwAAP3sAAAY7QAAGe0A
AEjtAABK7QAAiO0AAMjtAAAK7gAATO4AAI7uAADQ7gAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA
AAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAUVAA+EAABehAAAAAEVAAAcCO4AAB3uAAAl7gAASO4AAEruAACK7gAAjO4A
AMzuAADO7gAADu8AABDvAABQ7wAAVO8AAJLvAACU7wAA1O8AANbvAAAW8AAAGPAAAFjwAABa8AAA
mvAAAJzwAACd8AAAnvAAANzwAADe8AAA3/AAAODwAAAe8QAAIPEAAGDxAABi8QAAovEAAKTxAADk
8QAA5vEAACbyAAAo8gAAdPIAANDyAADW8gAAOfMAAIb0AACH9AAAiPQAAIn0AACs9AAAufQAAN30
AADq9AAABfUAABL1AADd9QAA3/UAAPL1AAD69QAAH/YAACH2AABh9gAAY/YAAKP2AACl9gAA5fYA
AOf2AADo9gAA6fYAAAH3AAAR9wAAJ/cAACn3AABp9wAAa/cAAGz3AABt9wAAhfcAAJX3AACr9wAA
rfcAAO33AADv9wAA8PcAAPL3AABT+AAApvgAAKz4AAAV+QAAgfkAAP/5AAAW+gAAJ/oAAPL6AAD0
+gAACfsAABH7AAA0+wAANvsAAHb7AAB4+wAAuPsAALr7AAAA/QD9AP0A/QD9AP0A/QD9AP0A/QD9
AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A
/QD9AP0A/QD9AP0A/QD9AP0A/QD9AAADbygBAGTQ7gAAEu8AAFTvAACW7wAA2O8AABrwAABc8AAA
nvAAAODwAAAi8QAAZPEAAKbxAADo8QAAKvIAACvyAAAx8gAASPIAAEnyAABW8gAAdfIAAHbyAAA5
8wAAOvMAAEnzAACG8wAAtfMAALbzAADB8wAA7/MAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA
+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA
AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA
AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcA
AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAA
AAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAABFQAABRUAD4QAAF6EAAAAHO/zAADw8wAABfQAADn0AAA69AAATvQAAIT0AACF
9AAAhvQAAKv0AACs9AAAIPUAACH1AABf9QAAn/UAAOH1AAAj9gAAZfYAAKf2AADp9gAAK/cAAG33
AACv9wAA8fcAAPL3AADz9wAA+fcAAAz4AAAN+AAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAA
AAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAA
AAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAUVAA+EAABehAAAAAEVAAAcDfgAABP4AAAu+AAAL/gAADT4AABT+AAAFfkAABb5
AAAd+QAAUPkAAFL5AABf+QAAgvkAAIP5AACS+QAAsPkAALH5AADA+QAA3vkAAN/5AADg+QAA//kA
AAD6AAA0+gAANvoAAHT6AAC0+gAA9voAADj7AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAA
AAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3
AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAABRUAD4QAAF6EAAAAARUAABw4+wAAevsAALz7AAD++wAAQPwAAIL8AADE/AAABv0A
AEj9AACK/QAAzP0AAA7+AABQ/gAAkv4AANT+AAAW/wAAF/8AAB3/AAA0/wAANf8AAEL/AABh/wAA
Yv8AADkAAQA6AAEASQABAIYAAQC1AAEAtgABAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA
AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA
+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAA
AAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA
AAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcA
AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABFQAABRUAD4QAAF6EAAAAHLr7AAD6+wAA/PsAADz8AABA/AAAfvwAAID8AADA/AAA
wvwAAAL9AAAE/QAARP0AAEb9AACG/QAAiP0AAIn9AACK/QAAyP0AAMr9AADL/QAAzP0AAAr+AAAM
/gAATP4AAE7+AACO/gAAkP4AAND+AADS/gAAEv8AABT/AABg/wAAyP8AAM7/AAA5AAEAhgEBAIcB
AQCIAQEAiQEBAIoBAQCLAQEAjQEBAJ8BAQCwAQEAwQEBAOUBAQD2AQEAEQIBACICAQDtAgEA7wIB
AAIDAQAKAwEALwMBADEDAQBxAwEAcwMBALMDAQC1AwEA9QMBAPcDAQD4AwEA+QMBABEEAQAhBAEA
NwQBADkEAQB5BAEAewQBAHwEAQB9BAEAkwQBAKkEAQC7BAEAvQQBAP0EAQD/BAEAAAUBAAIFAQBi
BQEAwwUBAMgFAQA1BgEAoQYBAMQGAQDHBgEAJQcBAHAHAQBzBwEAjgcBAMAHAQDBBwEAGQgBAAD9
AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A
/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A9Or0AAAAABNDShgAT0oDAFFKAwBeSgMAbygB
EENKGABPSgMAUUoDAF5KAwAAA28oAQBctgABAMEAAQDvAAEA8AABAAUBAQA5AQEAOgEBAE4BAQCE
AQEAhQEBAIYBAQCvAQEAsAEBADACAQAxAgEAbwIBAK8CAQDxAgEAMwMBAHUDAQC3AwEA+QMBADsE
AQB9BAEAvwQBAAEFAQACBQEAAwUBAAkFAQD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAA
AAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAA
AAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAABRUAD4QAAF6EAAAAARUAABwJBQEAHAUBAB0FAQAjBQEAPgUBAD8FAQBEBQEAZAUBADUG
AQA2BgEAPQYBAHAGAQByBgEAfwYBAKIGAQCjBgEAsgYBANAGAQDRBgEA5wYBAAwHAQANBwEADgcB
ACUHAQAmBwEAcAcBAHEHAQByBwEA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAA
AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA7wAAAAAAAAAA
AAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcVAA+EkAFWRMgA
XoSQAQAFFQAPhAAAXoQAAAABFQAAG3IHAQCNBwEAjgcBABoIAQAbCAEAHAgBACoIAQArCAEALAgB
AC0IAQAuCAEARAgBAEUIAQBTCAEAgwgBAKYIAQC0CAEAywgBAOMIAQDkCAEA8wgBAC8JAQBPCQEA
XQkBAHQJAQCMCQEAjQkBAJoJAQD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA
AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA
AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA
AAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA
6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAA
AAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAA
AAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAAAAAAAABxUAD4SQAVZEyABehJABAAcaAA+EkAFW
RMgAXoSQAQAFFQAPhAAAXoQAAAAbGQgBAB0IAQAsCAEALwgBAEUIAQC0CAEAuwgBAMsIAQDSCAEA
ewkBAIsJAQAiCgEAJQoBACYKAQAoCgEA3goBAIMLAQCECwEA2AsBANkLAQDMDAEAzQwBABYOAQAX
DgEAPA4BAN0OAQDkDgEALQ8BADAPAQAxDwEANw8BADgPAQA5DwEAOw8BAEgPAQBJDwEAaQ8BAGoP
AQCCDwEAgw8BAIkPAQCKDwEAjA8BAI0PAQCPDwEAkg8BAJ0PAQCeDwEAwQ8BAMkPAQDTDwEA2Q8B
ANoPAQDgDwEA4Q8BAOIPAQDjDwEA5Q8BAOgPAQDpDwEA6w8BAO4PAQBLEAEAThABALQQAQDPEAEA
0BABAOIQAQDjEAEAKxEBACwRAQBMEQEATREBAJMRAQCUEQEAqBEBAKkRAQDQEQEA0REBAO4RAQDv
EQEANxIBADgSAQBYEgEAWRIBAIUSAQCGEgEApxIBAKgSAQDzEgEA9BIBABkTAQAaEwEAZBMBAP0A
/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD28/bzAP0A/QD99vP26/b9AP0A/QD9APbz9uv2/QD9
AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QAPMEoSAG1IAARuSAAEdQgBBDBKEgAA
DQNqAAAAADBKEgBVCAEDbygBAF2aCQEA1gkBAPYJAQAECgEAGwoBADQKAQA1CgEAQAoBAHwKAQCc
CgEAqgoBAMEKAQDZCgEA2goBANsKAQD3CgEA+AoBAIQLAQAXDgEAWw4BAN0OAQDeDgEA3w4BAOAO
AQDhDgEA4g4BAOMOAQDkDgEA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA
9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAA
AAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA
AAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAPcA
AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAADxAAAAAAAA
AAAAAAAA6wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAA
AO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAAAAAAAAAAAAABEQAAAQAAAAEWAAAFFQAPhAAAXoQA
AAAHFQAPhJABVkTIAF6EkAEAG+QOAQAtDwEALg8BAC8PAQAwDwEAOQ8BADoPAQA7DwEAPA8BAI8P
AQCQDwEAkg8BAOUPAQDmDwEA6A8BAOkPAQDqDwEA6w8BAEsQAQC1EAEAEBEBAIMRAQDAEQEAJxIB
AHESAQD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA
6gAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAOAAAAAA
AAAAAAAAAADiAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAADiAAAAAAAAAAAA
AAAA5AAAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAANIA
AAAAAAAAAAAAAADSAAAAAAAAAAAAAAAA0gAAAAAAAAAAAAAAANIAAAAAAAAAAAAAAADSAAAAAAAA
AAAAAAAA0gAAAAAAAAAAAAAAANIAAAAAAAAAAAAAAAAAAAAAAAAAAAANFQAPhOADEYTK/VZE1QBX
RBT/XoTgA2CEyv0AAREAAAEAAAAFEQAOhGgBXYRoAQAIEQAYhPj/GYQBABsmYCMkAgABEAAABBAA
AyQBYSQBBRAADcYEAbATAAAYcRIBANoSAQBIEwEAxxMBABwUAQCaFAEA4hQBAOMUAQDkFAEA8QAA
AAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAA
AAAAAADxAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFFQAPhAAAXoQAAAABAAAADRUAD4TgAxGEyv1W
RNUAV0QU/16E4ANghMr9AAhkEwEAZRMBAJETAQCSEwEAxxMBAMgTAQDKEwEA0xMBANYTAQDXEwEA
2BMBABsUAQAhFAEAKxQBAC8UAQBpFAEAahQBAI0UAQCOFAEAkxQBAJQUAQCZFAEAmhQBAJsUAQCd
FAEApRQBAKoUAQDaFAEA3BQBAOQUAQAA/QD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A/QD9AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAANvKAEAHSsACjABJlAFAB+w0C8gsGA7IbAAACKwUAcjkOABJJAAACWwAAAXsDcC
GLA3AisACjABJlAFAB+w0C8gsGA7IbAAACKwUAcjkCwBJJAAACWwAAAXsAAAGLAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAFABgAAoAAQBpAA8AAwAAAAUAAAAAACwAAEDx/wIALAAMAAIAXNQAyQAA
AgAAABQAX0gBBG1ICQRuSBIEc0gJBHRIEgQ+AAEAAQACAD4ADAAEABzIqbogADEAAAAQAAEABiQB
E6TwABSkPABAJgATADUIgUNKHABLSBwAT0oCAFFKAgAAagACAAEAAgBqAAwAGwAcyKm6IAAyACwA
aAAyACwAMgBuAGQAIABsAGUAdgBlAGwALABoAGUAYQBkAGkAbgBnACAAMgAAABAAAgAGJAETpPAA
FKQ8AEAmARIANQiBNgiBQ0oYAE9KAgBRSgIARgADAAEAAgBGAAwABAAcyKm6IAAzAAAAIAADAAYk
AQ+ELAERhDD4QCYCVkQsAVdEOP9ehCwBYIQw+AwAT0oCAFBKBgBRSgIAQAAEAAEAAgBAAAwABAAc
yKm6IAA0AAAAIAAEAAYkAQ+EkAERhDD4QCYDVkSQAVdEOP9ehJABYIQw+AYANQiBXAiBRgAFAAEA
AgBGAAwABAAcyKm6IAA1AAAAIAAFAAYkAQ+E9AERhDD4QCYEVkT0AVdEOP9ehPQBYIQw+AwAT0oC
AFBKBgBRSgIAQAAGAAEAAgBAAAwABAAcyKm6IAA2AAAAIAAGAAYkAQ+EWAIRhDD4QCYFVkRYAldE
OP9ehFgCYIQw+AYANQiBXAiBOgAHAAEAAgA6AAwABAAcyKm6IAA3AAAAIAAHAAYkAQ+EvAIRhDD4
QCYGVkS8AldEOP9ehLwCYIQw+AAAOgAIAAEAAgA6AAwABAAcyKm6IAA4AAAAIAAIAAYkAQ+EIAMR
hDD4QCYHVkQgA1dEOP9ehCADYIQw+AAAOgAJAAEAAgA6AAwABAAcyKm6IAA5AAAAIAAJAAYkAQ+E
hAMRhDD4QCYIVkSEA1dEOP9ehIQDYIQw+AAAIABBQPL/oQAgAAwACAAwrvi8IADosn23IAAArjSv
AAAAAAAAAAAAAAAAIgBaAAEA8gAiAAwAAwAArpDHzLkAAAIADwAIAE9KAwBRSgMAOAAfQAEAAgE4
AAwAAwA4uqy5AK4AABMAEAASZBD/AAANxggAArATYCcBAgAMAENKGABPSgMAUUoDADgAIEABABIB
OAAMAAMAFLzlsgCuAAATABEAEmQQ/wAADcYIAAKwE2AnAQIADABDShgAT0oDAFFKAwAcAClAogAh
ARwADAAGAJjTdMfAySAAiLw41gAAAAAqAFkAAQAyASoADAAFADi7HMEgAGytcMgAAAYAEwAtRCAB
CABPSgcAUUoHACAAVUCiAEEBIAAMAAUAWNV0x3zTwbls0AAABgA+KgFCKgI+AP5PAQBSAT4ADAAI
AFIARgBDACAAVABlAHgAdAAAABAAFQAPhLABEmQQ/wAAXoSwAQwAQ0oYAE9KAwBRSgMAPAD+TwEA
UgE8AAwACwBSAEYAQwAgAEgAZQBhAGQAaQBuAGcAAAAIABYAEmQQ/wAADABDShgAT0oDAFFKAwAw
ACtAUQFyATAADAAGAPi7/MggAE3RpMK40gAAEgAXAA+EYAMRhFD+XoRgA2CEUP4AAB4AKkDy/4EB
HgAMAAUA+Lv8yCAAOMxwyAAAAwBIKgAALgBWQKIAkQEuAAwACQD0xbTF+LwgAFjVdMd808G5bNAA
AAwAPioBQioMcGiAAIAAfABlQAEAogF8AAwAEQBIAFQATQBMACAAUAByAGUAZgBvAHIAbQBhAHQA
dABlAGQAAAA3ABoADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAA
AAAAAAAAAAAAEABPSggAUEoIAFFKCABeSggAJAAdAAEAsgEkAAwABgABrPzIIABN0aTCuNIAAAUA
GwBHJAAAAAAsAE8AAQACACwADAAJAAGs/MgvAPi7/MggADi6rLkArgAACAAcAAMkAWEkAQAANgAj
AAEAAgA2AAwABQD4rby5IACpuijMAAAaAB0AD4RSAxGEV/5WRJABV0Q4/16EUgNghFf+AAAoADAA
AQDiASgADQAGAACuOLqsuSAAMK441gAACQAeAAomAAtGFQAAAAAsADYAAQDyASwADQAIAACuOLqs
uSAAMK441iAAMgAAAAkAHwAKJgALRhkAAAAALAA3AAEAAgIsAA0ACAAArji6rLkgADCuONYgADMA
AAAJACAACiYAC0YaAAAAACwAOAABABICLAANAAgAAK44uqy5IAAwrjjWIAA0AAAACQAhAAomAAtG
FgAAAAAsADkAAQAiAiwADQAIAACuOLqsuSAAMK441iAANQAAAAkAIgAKJgALRhsAAAAAGABMAAEA
AgAYAAwAAgCgsNzJAAACACMAAACCAC0A8f9CAoIADAAHAOS5bNBcuCAATdGkwrjSAAA6ACQADcYm
AAypAVMD/ASlBk4I9wmgC0oN8w6cEEUS7hMAAAAAAAAAAAAAAAAzJAA1JAA3JAA4JABHJAAoAENK
GABPSgMAUUoDAF5KAwBfSAEEYUoYAG1ICQRuSBIEc0gJBHRIEgQmAD8AAQBSAiYADAADAPq5TMfQ
uQAADgAlAA+EZABWRDQIXoRkAAAAIAAeAAEAYgIgAAwABgBUuqi6IABN0aTCuNIAAAIAJgAAAKAA
SQABAHICoAAMAAcAVLrcwsDJIAA4uqy5AK4AAGsAJwAPhMADEYRA/CRkBgEAASVkBgEAASZkBgEA
ASdkBgEAAS1EABBNxgoAAAD/AAAA/wQATsYIAAAA/wYBAQBPxggAAAD/BgEBAFDGCAAAAP8GAQEA
UcYIAAAA/wYBAQBXRHD+XoTAA2CEQPwAFABDShgAT0oCAFFKAgBeSgIAYUoYADAALwABAIICMAAM
AAIAqbpduAAAGgAoAA+EZAARhDj/VkTIAFdEOP9ehGQAYIQ4/wAANAAyAAEAkgI0AAwABACpul24
IAAyAAAAGgApAA+EZAARhDj/VkSQAVdEOP9ehGQAYIQ4/wAANAAzAAEAogI0AAwABACpul24IAAz
AAAAGgAqAA+EZAARhDj/VkRYAldEOP9ehGQAYIQ4/wAANAA0AAEAsgI0AAwABACpul24IAA0AAAA
GgArAA+EZAARhDj/VkQgA1dEOP9ehGQAYIQ4/wAANAA1AAEAwgI0AAwABACpul24IAA1AAAAGgAs
AA+EZAARhDj/VkToA1dEOP9ehGQAYIQ4/wAALgBEAAEA0gIuAAwABQCpul24IADErI3BAAASAC0A
D4SpARSktABWRMgAXoSpAQAAMgBFAAEA4gIyAAwABwCpul24IADErI3BIAAyAAAAEgAuAA+EUgMU
pLQAVkSQAV6EUgMAADIARgABAPICMgAMAAcAqbpduCAAxKyNwSAAMwAAABIALwAPhPsEFKS0AFZE
WAJehPsEAAAyAEcAAQACAzIADAAHAKm6XbggAMSsjcEgADQAAAASADAAD4SkBhSktABWRCADXoSk
BgAAMgBIAAEAEgMyAAwABwCpul24IADErI3BIAA1AAAAEgAxAA+ETQgUpLQAVkToA16ETQgAABwA
EwABAAIAHAANAAQAqboozCAAMQAAAAIAMgAAACgAFAABAAIAKAANAAQAqboozCAAMgAAAA4AMwAP
hKkBVkTIAF6EqQEAACgAFQABAAIAKAANAAQAqboozCAAMwAAAA4ANAAPhFIDVkSQAV6EUgMAACgA
FgABAAIAKAANAAQAqboozCAANAAAAA4ANQAPhPsEVkRYAl6E+wQAACgAFwABAAIAKAANAAQAqboo
zCAANQAAAA4ANgAPhKQGVkQgA16EpAYAACgAGAABAAIAKAANAAQAqboozCAANgAAAA4ANwAPhE0I
VkToA16ETQgAACgAGQABAAIAKAANAAQAqboozCAANwAAAA4AOAAPhPYJVkSwBF6E9gkAACgAGgAB
AAIAKAANAAQAqboozCAAOAAAAA4AOQAPhJ8LVkR4BV6EnwsAACgAGwABAAIAKAANAAQAqboozCAA
OQAAAA4AOgAPhEgNVkRABl6ESA0AADAAJQABALIDMAAMAAYAGLyhwanGIAAJvSzSAAAFADsARyQA
AAwAT0oCAFFKAgBeSgIAKAAxAAEAwgMoAAwABgCIvDjWIADkuTCuMK4AAAkAPAAKJgALRhwAAAAA
LAA6AAEA0gMsAAwACACIvDjWIADkuTCuMK4gADIAAAAJAD0ACiYAC0YdAAAAACwAOwABAOIDLAAM
AAgAiLw41iAA5LkwrjCuIAAzAAAACQA+AAomAAtGHgAAAAAsADwAAQDyAywADAAIAIi8ONYgAOS5
MK4wriAANAAAAAkAPwAKJgALRh8AAAAALAA9AAEAAgQsAAwACACIvDjWIADkuTCuMK4gADUAAAAJ
AEAACiYAC0YgAAAAABwAQgABABIEHAAMAAIA+Lw4uwAABgBBABSktAAAACYAUAABACIEJgAMAAQA
+Lw4uyAAMgAAAAwAQgASZOABAQAUpLQAAAAoAFEAAQAyBCgADAAEAPi8OLsgADMAAAAGAEMAFKS0
AAgAQ0oQAGFKEAAyAEMAAQBCBDIADAAHAPi8OLsgAOS07MXwxDCuAAASAEQAD4RTAxSktABWRJAB
XoRTAwAAPABSAAEAUgQ8AAwACQD4vDi7IADktOzF8MQwriAAMgAAABgARQAPhFMDEmTgAQEAFKS0
AFZEkAFehFMDAAA+AFMAAQBiBD4ADAAJAPi8OLsgAOS07MXwxDCuIAAzAAAAEgBGAA+EUwMUpLQA
VkSQAV6EUwMIAENKEABhShAANgBNABEEcgQ2AAwACwD4vDi7IACrzCAABMkgAOS07MXwxDCuAAAO
AEcAEYTSAFdEZABghNIAAAA6AE4AQQSCBDoADAANAPi8OLsgAKvMIAAEySAA5LTsxfDEMK4gADIA
AAAOAEgAEYTSAFdEZABghNIAAABEAEoAAQCSBEQADAACAIC9HMgAAA8ASQADJAEUpDwAQCYBYSQB
AB4ANgiBQ0oYAE9KAgBQSgYAUUoCAF0IgV5KAgBhShgAPABUAAEAogQ8AAwABgAUvl24IABN0aTC
uNIAAB4ASgAOhKAFD4SgBRSktABVRLwCVkS8Al2EoAVehKAFAAA0AAoAAQACADQADQAEAMnAeMcg
ADEAAAAaAEsAD4TIABGEMPhWRMgAV0Q4/16EyABghDD4AAA0AAsAAQACADQADQAEAMnAeMcgADIA
AAAaAEwAD4SQARGEMPhWRJABV0Q4/16EkAFghDD4AAA0AAwAAQACADQADQAEAMnAeMcgADMAAAAa
AE0AD4RYAhGEMPhWRFgCV0Q4/16EWAJghDD4AAA0AA0AAQACADQADQAEAMnAeMcgADQAAAAaAE4A
D4QgAxGEMPhWRCADV0Q4/16EIANghDD4AAA0AA4AAQACADQADQAEAMnAeMcgADUAAAAaAE8AD4To
AxGEMPhWROgDV0Q4/16E6ANghDD4AAA0AA8AAQACADQADQAEAMnAeMcgADYAAAAaAFAAD4SwBBGE
MPhWRLAEV0Q4/16EsARghDD4AAA0ABAAAQACADQADQAEAMnAeMcgADcAAAAaAFEAD4R4BRGEMPhW
RHgFV0Q4/16EeAVghDD4AAA0ABEAAQACADQADQAEAMnAeMcgADgAAAAaAFIAD4RABhGEMPhWREAG
V0Q4/16EQAZghDD4AAA0ABIAAQACADQADQAEAMnAeMcgADkAAAAaAFMAD4QIBxGEMPhWRAgHV0Q4
/16ECAdghDD4AAAwACEAAQCyBDAADAAFAMnAeMcgABzIqboAAAIAVAASADUIgU9KAgBRSgIAXAiB
XkoCACQAQAABAFIFJAAMAAIAHMGFugAADgBVAA+EZABWRDQIXoRkAAAAGgBLAAEAAgAaAAwAAwB4
x6zA0LkAAAIAVgAAACQAWwABAHIFJAAMAAgABMiQxyAAVLp8xyAAHMGFugAAAgBXAAAAWAAkAAEA
ggVYAAwABQD8yIzBIAAJvSzSAAAoAFgAD4RkABiE/P8ZhPT/GoSUGhsmgCtE3AgvhI4ARyQAVkR4
BV6EZAAUAENKGABPSgIAUUoCAF5KAgBhShgASAA+AAEAkgVIAAwAAgDByWjVAAATAFkAAyQBE6Tw
ABSkeABAJgBhJAEAHgA1CIFDSiAAT0oCAFBKBgBRSgIAXAiBXkoCAGFKIAA4ACwAAQACADgADAAI
ADjM4KwgADi7zNUgAKm6KMwAABYAWgAPhKkBEYRX/ldEOP9ehKkBYIRX/gAARgAuAAEAAgBGAAwA
CwA4zOCsIAA4u8zVIACpuijMIAAcyKm6AAAGAFsAE6R4ABgAQ0oYAE9KAgBQSgYAUUoCAF5KAgBh
ShgAJgAiAAEAAgAmAAwAAgChzljBAAAKAFwAE6R4ABSk8AAGADUIgVwIgSgAXgABANIFKAAMAAYA
XNQAySAAKAD5xikAAAACAF0ACABDShgAYUoYAC4AHAABAOIFLgAMAAcAXNQAySAA5LTsxfDEMK4A
AA4AXgAPhCADVkSQAV6EIAMAADIAYAABAPIFMgAMAAwASABUAE0ATAAgAEEAZABkAHIAZQBzAHMA
AAACAF8ABgA2CIFdCIGeAQAA8QgAAOQQAQABAAEAAAAAAGAAAAD3BAAA+gQAAAAAAAAsBAEA5BAB
AAQAAKYBAAAA/////wQALaYBAAAA/////wAAAAATAAAAIQAAACIAAAAxAAAANgAAADcAAABjAAAA
cgAAAHMAAAB0AAAAeQAAAHoAAAB7AAAAiAAAAIkAAACKAAAAjwAAAJAAAACRAAAAnAAAAJ0AAACe
AAAAowAAAKQAAAClAAAAtAAAALUAAAC2AAAAtwAAAN4AAAD3AAAAGwEAABwBAAAdAQAAMQEAADIB
AACjAQAApAEAAFICAABTAgAAGAMAABkDAADoBAAASwUAAK0FAACuBQAArwUAALgFAAC5BQAAhAYA
AB8IAAAgCAAAIQgAAC0IAAAuCAAA9QgAAPYIAAD3CAAACQkAAAoJAAAaCQAAUQkAAHMJAACjCQAA
vwkAAO8JAAAOCgAAJwoAAE0KAABuCgAAmAoAALsKAADbCgAA9QoAABMLAAAzCwAATQsAAIALAACq
CwAAxQsAAOQLAAD7CwAAFgwAACQMAAA6DAAAVgwAAFcMAABYDAAAWQwAAFoMAABbDAAAXAwAAF0M
AABeDAAAXwwAAGAMAABhDAAAYgwAAGMMAABkDAAAZQwAAGYMAABnDAAAdwwAAHgMAACVDgAAlg4A
AB4RAAAfEQAAWxMAAFwTAADLFQAAzBUAAAQXAAAFFwAAuxkAALwZAAA6HAAAOxwAADwcAABzHAAA
dBwAAJYcAACXHAAAFB0AABUdAACSHQAAIx4AABsfAAD6IAAAnSEAAJ4hAAD8IQAA/SEAAMoiAABn
IwAAaCMAAFUlAABWJQAAVyUAAIclAACIJQAAlycAAJgnAAAAKQAAASkAAEksAABKLAAA2y4AANwu
AAAcLwAAXC8AAJwvAADcLwAAHDAAAFwwAACcMAAA3DAAABExAABRMQAAkTEAANExAAARMgAAUTIA
AJEyAADLMgAACzMAACczAABDMwAAXzMAAGAzAAB3MwAAkzMAAKIzAAC0MwAAxDMAANMzAADUMwAA
EzQAADM0AAA0NAAANTQAAHs2AAB8NgAAajkAAGs5AABGOwAARzsAAAI9AAADPQAAPUIAAD5CAAAe
QwAAH0MAADBDAABBQwAAb0MAAHBDAABxQwAAoEMAANZDAAAWRAAAVkQAAJZEAADWRAAAFkUAAFZF
AACWRQAAy0UAAAtGAABLRgAAi0YAAMtGAAALRwAAS0cAAIVHAADFRwAA4UcAAP1HAAAZSAAAGkgA
AFlIAAB/SAAAgEgAAIFIAADcSQAA3UkAAAxLAAANSwAASUsAAGdLAADCSwAAw0sAAP5MAAD/TAAA
k08AAJRPAAAmUgAAJ1IAABZTAAAXUwAAbFMAAG1TAABuUwAAilMAAItTAACNVAAAjlQAAPRUAAD1
VAAA9lQAACZVAAAnVQAARlUAAEdVAABIVQAASVUAAEpVAABLVQAATFUAAE1VAABOVQAAbVUAAG5V
AACHVQAAiFUAAP5WAAD/VgAADVgAAA5YAAAPWAAANVgAADZYAACJWAAAilgAALdYAADiWAAAKlkA
ACtZAAD0WQAA9VkAAFVaAABWWgAAV1oAAHhaAAB5WgAA91wAAPhcAAA5XQAAel0AALtdAAD8XQAA
PV4AAH5eAAC/XgAAAF8AAEFfAACCXwAAw18AAARgAABFYAAAhmAAAMdgAAAIYQAASWEAAIphAADL
YQAADGIAAE1iAACOYgAAz2IAABBjAAARYwAAS2MAAExjAAB8ZQAAfWUAAK9nAACwZwAAsWcAANtn
AADcZwAAWmkAAFtpAACNaQAAvmkAAO9pAAAgagAAUWoAAIJqAACzagAA5GoAAOVqAAAiawAAI2sA
ABFtAAASbQAAE20AADZtAAA3bQAAdm4AAHduAACrbgAA3m4AABFvAABEbwAAd28AAKpvAADdbwAA
3m8AABpwAAAbcAAACnEAAAtxAABCcgAAQ3IAAERyAACGcgAAyHIAAApzAABMcwAAjnMAANBzAAAS
dAAAVHQAAJZ0AADYdAAAGnUAAFx1AACedQAA4HUAACJ2AABkdgAApnYAAOh2AAAqdwAAbHcAAK53
AADwdwAA8XcAADd4AAA4eAAAOXgAAFl4AABaeAAAaXoAAGt6AACXegAAyXoAAAZ7AABDewAAgHsA
ALh7AADwewAAKHwAAGB8AACYfAAA1XwAABJ9AABPfQAAYn0AAGN9AACJfQAAin0AAIt9AADMfQAA
DX4AAE5+AACPfgAA0H4AABF/AABSfwAAk38AANR/AAAVgAAAVoAAAJeAAADYgAAAGYEAAFqBAACb
gQAA3IEAAB2CAABeggAAn4IAAKGCAADOggAAz4IAANCCAAAJgwAACoMAAFWDAACKgwAA2YMAAE6E
AACrhAAA6IQAAOmEAADqhAAAAYUAAAKFAACyhQAAoYYAAKKGAADRhgAA0oYAAAeHAAAnhwAASocA
AEuHAABMhwAAe4cAALeHAADzhwAAL4gAAGaIAACdiAAA1IgAAAuJAABCiQAAfokAALqJAAD2iQAA
CYoAAAuKAAA1igAANooAADeKAAA4igAAOYoAAHyKAAC9igAA/4oAAEGLAACDiwAAxYsAAAeMAABJ
jAAAi4wAAM2MAAAPjQAAUY0AAJONAADVjQAAF44AAFmOAACbjgAA3Y4AAB+PAABhjwAAo48AAOWP
AAAnkAAAaZAAAKuQAADtkAAAL5EAAHGRAACzkQAA9ZEAADeSAAB5kgAAu5IAAP2SAAA/kwAAgZMA
AMOTAAAFlAAAR5QAAImUAACKlAAAvJQAAL2UAAC+lAAA/JQAAP2UAABclQAA2JUAAE6WAACElgAA
hZYAAIaWAACHlgAAiJYAAImWAACKlgAAi5YAAIyWAACqlgAAq5YAAMuWAADMlgAAwpcAAMOXAADE
lwAA1JcAANWXAAAsmAAALZgAAGuYAACrmAAA7ZgAAC+ZAADGmQAACJoAACqaAABMmgAATZoAAE6a
AABWmgAAi5oAAIyaAACYmgAA3JoAAN2aAADsmgAAOJsAADmbAAA6mwAAXJsAAF2bAADLmwAAzJsA
AK+cAACwnAAA7pwAAC6dAABwnQAAsp0AAPSdAAA2ngAAeJ4AALqeAAD8ngAAPp8AAGCfAACCnwAA
g58AAImfAACtnwAArp8AALSfAADgnwAA4Z8AAOafAAAYoAAAGaAAACCgAABToAAAVKAAAFqgAADD
oAAAxKAAAMWgAAD2oAAA96AAAH+hAACAoQAAoqEAAL2hAADZoQAA86EAABGiAAAtogAAT6IAAG+i
AABwogAAcaIAAN6jAADfowAACqQAADOkAABfpAAAjqQAAL2kAADqpAAAHaUAAE6lAABPpQAAUKUA
AGqlAABrpQAApKYAAKWmAACmpgAA06YAANemAAANpwAAD6cAAE2nAACNpwAAz6cAABGoAABTqAAA
lagAANeoAAAZqQAAW6kAAJ2pAADfqQAAIaoAAGOqAAClqgAA56oAACmrAABrqwAArasAAO+rAADw
qwAA9qsAAA2sAAAOrAAAG6wAADqsAAA7rAAASqwAAIesAAC2rAAAt6wAAMKsAADwrAAA8awAAAat
AAA6rQAAO60AAE+tAACFrQAAhq0AAIetAAC1rQAAtq0AAEWuAABGrgAAhK4AAMSuAAAGrwAASK8A
AIqvAADMrwAADrAAAFCwAACSsAAA1LAAABaxAABYsQAAmrEAANyxAAAesgAAYLIAAKKyAACjsgAA
qbIAALyyAAC9sgAAw7IAAN6yAADfsgAA5LIAAOuyAADssgAA87IAACazAAAnswAANbMAAGKzAABj
swAAabMAAJSzAACVswAAm7MAAM6zAADPswAA1bMAAAG0AAACtAAACrQAADK0AAAztAAAOrQAAE+0
AABQtAAAWLQAAHS0AAB1tAAAfrQAAJO0AACUtAAAobQAAMS0AADFtAAA0LQAAAC1AAABtQAAEbUA
AD+1AABAtQAAT7UAAGa1AABntQAAaLUAAIK1AACDtQAAWLcAAFm3AABatwAAhbcAAIa3AAC3twAA
u7cAAPm3AAA5uAAAe7gAAL24AAD/uAAAQbkAAIO5AADFuQAAB7oAAEm6AACLugAAzboAAA+7AABR
uwAAk7sAANW7AAAXvAAAWbwAAJu8AACcvAAAorwAALm8AAC6vAAAx7wAAOa8AADnvAAA9rwAAGa9
AABnvQAAcr0AAKC9AAChvQAAtr0AAOq9AADrvQAA/70AADW+AAA2vgAAN74AAGK+AABjvgAAmL4A
AJm+AADXvgAAF78AAFm/AACbvwAA3b8AAB/AAABhwAAAo8AAAOXAAAAnwQAAacEAAKvBAADtwQAA
L8IAAHHCAABywgAAeMIAAIvCAACMwgAAksIAAK3CAACuwgAAs8IAALrCAAC7wgAAwsIAAPXCAAD2
wgAAAMMAAEXDAABGwwAAT8MAAGTDAABlwwAAcsMAAJXDAACWwwAAocMAANHDAADSwwAA4cMAAPbD
AAD3wwAAN8QAAFDEAABRxAAAacQAALHEAACyxAAAA8UAAATFAAAFxQAAOMUAADnFAAAGxgAAB8YA
ABjGAAAZxgAAQ8YAAIXGAADHxgAACccAABLHAABDxwAARMcAAGTHAABlxwAAhMcAAIzHAADVxwAA
28cAANzHAADdxwAA/scAAP/HAAA9yAAAfcgAAL/IAAAByQAAQ8kAAIXJAADHyQAACcoAAEvKAACN
ygAAz8oAABHLAABTywAAlcsAANfLAADYywAA6csAAOrLAAAIzAAACcwAAEzMAABNzAAAf8wAAIDM
AADGzAAA88wAAPTMAAAmzQAAJ80AAGrNAACwzQAAsc0AAOjNAAD4zQAA+c0AACvOAAA7zgAAPM4A
AD3OAABdzgAAXs4AAJzOAADczgAAHs8AAGDPAACizwAA5M8AACbQAAAn0AAAN9AAADjQAABX0AAA
WNAAAJvQAACc0AAAztAAAM/QAAAM0QAADdEAAA7RAAA40QAAOdEAADbTAAA30wAAONMAAF3TAABf
0wAAkNMAAJLTAADQ0wAAENQAAFLUAACU1AAA1tQAABjVAABa1QAAnNUAAN7VAAAg1gAAYtYAAKTW
AADm1gAAKNcAAGrXAACs1wAA7tcAADDYAABy2AAAc9gAAHnYAACQ2AAAkdgAAJ7YAAC92AAAvtgA
AM3YAAAK2QAAOdkAADrZAABF2QAAc9kAAHTZAACJ2QAAvdkAAL7ZAADS2QAACNoAAAnaAAAK2gAA
MNoAADHaAACo2gAAqdoAAOfaAAAn2wAAadsAAKvbAADt2wAAL9wAAHHcAABy3AAAeNwAAIvcAACM
3AAAktwAAK3cAACu3AAAs9wAANLcAADT3AAA2twAAA3dAAAP3QAAHN0AAD/dAABA3QAAQd0AAGnd
AABr3QAAn90AAKHdAADf3QAAH94AAGHeAACj3gAA5d4AACffAABp3wAAq98AAO3fAAAv4AAAceAA
ALPgAAD14AAAN+EAAHnhAAC74QAA/eEAAD/iAACB4gAAguIAAIjiAACf4gAAoOIAAK3iAADM4gAA
zeIAANziAAAZ4wAASOMAAEnjAABU4wAAguMAAIPjAACY4wAAzOMAAM3jAADh4wAAF+QAABjkAAAZ
5AAAQuQAAEPkAADD5AAAxOQAAALlAABC5QAAhOUAAMblAAAI5gAASuYAAIzmAADO5gAAEOcAAFLn
AACU5wAAlecAAJvnAACu5wAAr+cAALXnAADQ5wAA0ecAANbnAAD15wAA9ucAAP3nAAAw6AAAMegA
ADroAACK6AAAjOgAAJnoAAC86AAAvegAAM3oAAD76AAA/OgAAP3oAAAY6QAAGekAAEjpAABK6QAA
iOkAAMjpAAAK6gAATOoAAI7qAADQ6gAAEusAAFTrAACW6wAA2OsAABrsAABc7AAAnuwAAODsAAAi
7QAAZO0AAKbtAADo7QAAKu4AACvuAAAx7gAASO4AAEnuAABW7gAAde4AAHbuAAA57wAAOu8AAEnv
AACG7wAAte8AALbvAADB7wAA7+8AAPDvAAAF8AAAOfAAADrwAABO8AAAhPAAAIXwAACG8AAAq/AA
AKzwAAAg8QAAIfEAAF/xAACf8QAA4fEAACPyAABl8gAAp/IAAOnyAAAr8wAAbfMAAK/zAADx8wAA
8vMAAPPzAAD58wAADPQAAA30AAAT9AAALvQAAC/0AAA09AAAU/QAABX1AAAW9QAAHfUAAFD1AABS
9QAAX/UAAIL1AACD9QAAkvUAALD1AACx9QAAwPUAAN71AADf9QAA4PUAAP/1AAAA9gAANPYAADb2
AAB09gAAtPYAAPb2AAA49wAAevcAALz3AAD+9wAAQPgAAIL4AADE+AAABvkAAEj5AACK+QAAzPkA
AA76AABQ+gAAkvoAANT6AAAW+wAAF/sAAB37AAA0+wAANfsAAEL7AABh+wAAYvsAADn8AAA6/AAA
SfwAAIb8AAC1/AAAtvwAAMH8AADv/AAA8PwAAAX9AAA5/QAAOv0AAE79AACE/QAAhf0AAIb9AACv
/QAAsP0AADD+AAAx/gAAb/4AAK/+AADx/gAAM/8AAHX/AAC3/wAA+f8AADsAAQB9AAEAvwABAAEB
AQACAQEAAwEBAAkBAQAcAQEAHQEBACMBAQA+AQEAPwEBAEQBAQBkAQEANQIBADYCAQA9AgEAcAIB
AHICAQB/AgEAogIBAKMCAQCyAgEA0AIBANECAQDnAgEADAMBAA0DAQAOAwEAJQMBACYDAQBwAwEA
cQMBAHIDAQCNAwEAjgMBABoEAQAbBAEAHAQBACoEAQArBAEALAQBAC0EAQAuBAEARAQBAEUEAQBT
BAEAgwQBAKYEAQC0BAEAywQBAOMEAQDkBAEA8wQBAC8FAQBPBQEAXQUBAHQFAQCMBQEAjQUBAJoF
AQDWBQEA9gUBAAQGAQAbBgEANAYBADUGAQBABgEAfAYBAJwGAQCqBgEAwQYBANkGAQDaBgEA2wYB
APcGAQD4BgEAhAcBABcKAQBbCgEA3QoBAN4KAQDfCgEA4QoBAOMKAQAtCwEALgsBAC8LAQA7CwEA
PAsBAI8LAQCQCwEAkgsBAOULAQDmCwEA6AsBAOkLAQDrCwEASwwBALUMAQAQDQEAgw0BAMANAQAn
DgEAcQ4BANoOAQBIDwEAxw8BABwQAQCaEAEA4hABAOUQAQCpAAAAFgAAAAAAAAAAgAAAAICpAAAA
FjAAAAAAAAAAgAAAAICZAAAAADAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICpAAAAFjAA
AAAAAAAAgAAAAICZAAAAADAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICpAAAAFjAAAAAA
AAAAgAAAAICZAAAAADAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICpAAAAFjAAAAAAAAAA
gAAAAICZAAAAADAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICpAAAAFjAAAAAAAAAAgAAA
AICZAAAAADAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICpAAAAFjAAAAAAAAAAgAAAAICZ
AAAAADAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICpAAAAFjAAAAAAAAAAgAAAAICZAAAA
ADAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICpAAAAFjAAAAAAAAAAgAAAAICZAAAAADAA
AAAAAAAAgAAAAICpAAAAFjAAAAAAAAAAgAAAAICpAAAAFjAAAAAAAAAAgAAAAICZAAAAADAAAAAA
AAAAgAAAAICYAAAAFjAAAAAAAAAAgAAAAICYAAAAFjAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFjAAAAAAAAAAgAAA
AICYAAAAFjAAAAAAAAAAgAAAAICYAAAAFjAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICY
AAAAFwAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA
FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA
AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA
AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAA
AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA
gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA
AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY
AAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA
FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA
AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAA
AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA
gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA
AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYQAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA
AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY
AAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA
FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
QAAAFTAAAAAAAAAAgAAAAICYQAAAFTAAAAAAAAAAgAAAAICYQAAAFTAAAAAAAAAAgAAAAICYQAAA
FTAAAAAAAAAAgAAAAICYQAAAFTAAAAAAAAAAgAAAAICYQAAAFTAAAAAAAAAAgAAAAICYQAAAFTAA
AAAAAAAAgAAAAICYQAAAFTAAAAAAAAAAgAAAAICYQAAAFTAAAAAAAAAAgAAAAICYQAAAFTAAAAAA
AAAAgAAAAICYQAAAFTAAAAAAAAAAgAAAAICYQAAAFTAAAAAAAAAAgAAAAICYQAAAFTAAAAAAAAAA
gAAAAICYQAAAFTAAAAAAAAAAgAAAAICYQAAAFTAAAAAAAAAAgAAAAICYQAAAFTAAAAAAAAAAgAAA
AICYQAAAFTAAAAAAAAAAgAAAAICYQAAAFTAAAAAAAAAAgAAAAICYQAAAFTAAAAAAAAAAgAAAAICY
QAAAFTAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAA
FQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAA
AAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFTAAAAAAAAAAgAAAAICYQAAAFTAAAAAA
AAAAgAAAAICYQAAAFTAAAAAAAAAAgAAAAICYQAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAA
AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAAAAAA
AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA
gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA
AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
GgAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAGgAAAAAAAAAAgAAAAICYAAAAGjAA
AAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAA
AAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAA
gAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAA
AICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICY
AAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAA
GjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAA
AAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAA
AAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAA
gAAAAICYAAAAGgAAAAAAAAAAgAAAAICYAAAAGgAAAAAAAAAAgAAAAICYAAAAGgAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAGjAAAAAAAAAAgAAAAICYAAAAGgAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
GjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAA
AAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAA
AAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAA
gAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGgAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAGgAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAA
GjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAA
AAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAA
AAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGgAAAAAAAAAA
gAAAAICYAAAAGgAAAAAAAAAAgAAAAICYAAAAGgAAAAAAAAAAgAAAAICYAAAAGgAAAAAAAAAAgAAA
AICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICY
AAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAA
GjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAA
AAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAA
AAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAA
gAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAA
AICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICY
AAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAA
AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA
AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY
AAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAA
AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAA
AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA
gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA
gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA
AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA
gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA
AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY
AAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA
FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA
AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYQAAAFTAAAAAAAAAAgAAAAICYAAAAGgAAAAAAAAAA
gAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGgAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAA
AICYQAAAGgAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICY
QAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAA
GjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAA
AAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGgAAAAAA
AAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGgAAAAAAAAAA
gAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAA
AICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICY
QAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAA
GjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAA
AAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAA
AAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAA
gAAAAICYAAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAA
AICYQAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICY
QAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYAAAA
GjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAA
AAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAA
AAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAA
gAAAAICYQAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAGgAAAAAAAAAAgAAA
AICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICY
QAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAA
GjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAA
AAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAA
AAAAgAAAAICYAAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYAAAAGjAAAAAAAAAA
gAAAAICYQAAAGjAAAAAAAAAAgAAAAICYQAAAGjAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAGgAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAABgFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA
AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAA
AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA
gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA
AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY
AAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA
FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA
AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAA
AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFjAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA
AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY
AAAAFQAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICaQAAAETAAAAAAAAAAgAAAAICaQAAA
ETAAAAAAAAAAgAAAAICaQAAAADAAAAAAAAAAgAAAAICaQAAAEDAAAAAAAAAAgAAAAICYQAAAEDAA
AAAAAAAAgAAAAICYQAAAEDAAAAAAAAAAgAAAAIAKQAAAAHAAAAAAAAAAAAAAAACYQAAAETAAAAAA
AAAAgAAAAICYQAAAETAAAAAAAAAAgAAAAIAKQAAAADAAAAAAAAAAAAAAAACaQAAAETAAAAAAAAAA
gAAAAICaQAAAETAAAAAAAAAAgAAAAIAKQAAAADAAAAAAAAAAAAAAAACaQAAAETAAAAAAAAAAgAAA
AICYQAAAETAAAAAAAAAAgAAAAIAKAAAAADAAAAAAAAAAAAAAAACaQAAAFTAAAAAAAAAAgAAAAICY
QAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAA
FQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAA
AAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAA
AAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAIAKAAAAADAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAQAAAAGAAAABgAAAFIAAABdAAAAsgAAALIAAAAIAQAA
CAEAAAgBAAAIAQAACAEAAAgBAAAMAQAADwEAAAAEAABgKgAAxDQAAH4/AABQSwAAzGEAAExnAAD5
cAAAzX0AAAuMAACzpgAAOcIAAE/PAAAL3gAACO4AALr7AAAZCAEAZBMBAOQUAQCMAAAAlQAAAJYA
AACZAAAAmwAAAJ8AAACgAAAAogAAAKUAAACpAAAAsAAAALcAAAC8AAAAwAAAAMUAAADKAAAAzgAA
ANIAAAAABAAAkQQAADEFAAAJDQAAFhAAAFsXAAD9JQAAkTUAAEY/AACLSgAAlFMAAG5ZAAD4YAAA
TGcAAHdyAACeeQAAmIAAAB2GAACiigAAN44AACeUAADYmQAAxp0AADaiAAB/pQAApaoAAA6wAAAO
tAAAlLcAAE+5AABRvwAAmMIAAPXGAAA5yQAAhc0AAPnRAAA51QAAc9wAAKvfAACj4gAAgucAALXr
AADQ7gAA7/MAAA34AAA4+wAAtgABAAkFAQByBwEAmgkBAOQOAQBxEgEA5BQBAI0AAACPAAAAkAAA
AJEAAACSAAAAkwAAAJQAAACXAAAAmAAAAJoAAACcAAAAnQAAAJ4AAAChAAAAowAAAKQAAACmAAAA
pwAAAKgAAACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACxAAAAsgAAALMAAAC0AAAAtQAAALYAAAC4
AAAAuQAAALoAAAC7AAAAvQAAAL4AAAC/AAAAwQAAAMIAAADDAAAAxAAAAMYAAADHAAAAyAAAAMkA
AADLAAAAzAAAAM0AAADPAAAA0AAAANEAAAAABAAA4xQBAI4AAABSAAAAWQAAAKQAAACrAAAArgAA
APsAAAACAQAABAEAAA8BAAATIZUAEyH0/5WAEyH0/5WADwAA8GwAAAAAAAbwGAAAAAIIAAACAAAA
BQAAAAEAAAABAAAABgAAAB8AAfAsAAAAMgAH8CQAAAADBGQYrPzC3iws2g3IbgU0jmT/AF8GAAAA
AAAA/////wAA8QFAAB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC8JIAAAAQAAjwCAAAAAEAAAAF
BAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUA
AAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAA
AD8DAQABAAAAEfAEAAAAAQAAAOQQAQAAAAAAFwAAABsAAAAcAAAAIAAAAGMAAABmAAAAZwAAAG0A
AAB/AAAAggAAAJEAAACUAAAASQQAAFIEAAAECAAACAgAAMQJAADQCQAADgsAABILAAAuCwAAMgsA
AIsNAACODQAAUhIAAFYSAACwEgAAtBIAAO4SAADyEgAA6BgAAOsYAACVGwAAmRsAAEseAABPHgAA
pR4AAKgeAACIHwAAix8AAM4fAADRHwAAPiEAAEYhAAApIgAALSIAAHYoAAB5KAAAiDQAAIw0AACS
NAAAljQAAEo1AABONQAAgTUAAIU1AAC/NQAAwjUAAAk2AAANNgAAizcAAI43AAAAOgAAAzoAALI6
AAC1OgAAFUEAABhBAABUQQAAV0EAAHBLAABzSwAAc00AAHZNAAA6UgAAPVIAAPtUAAAHVQAA21YA
AN5WAAACWgAABVoAAFdbAABaWwAAN2QAADpkAADnZAAA6mQAAMVwAADIcAAA2XEAANxxAAB1hgAA
eIYAAGiPAABtjwAAxI8AAMmPAAAPkQAAEpEAAEWRAABIkQAAyZEAAMyRAAAYkgAAG5IAAICSAACF
kgAALZUAADCVAACllgAAqZYAAMaWAADKlgAA2pYAAN6WAADPlwAA05cAALieAAC5ngAAc7MAAHyz
AACbswAAqLMAAFC0AABXtAAAS8kAAFDJAABUyQAAWMkAAIrMAACPzAAA+swAAP7MAADGzQAAx80A
AOnNAADqzQAA8s0AAPfNAAAQzgAAEc4AACzOAAAtzgAANc4AADrOAABJBAEATQQBAE4EAQBSBAEA
iAQBAIsEAQCMBAEAjwQBAJYEAQCcBAEAngQBAKQEAQDkBAEA5wQBAOgEAQDuBAEAMwUBADkFAQA/
BQEARQUBAEcFAQBNBQEAkQUBAJQFAQDaBQEA4AUBAOYFAQDsBQEA7gUBAPQFAQA1BgEAOAYBAIAG
AQCGBgEAjAYBAJIGAQCUBgEAmgYBAN4KAQDeCgEA3woBAN8KAQDgCgEA4AoBAOEKAQDiCgEA4woB
AOQKAQA8CwEAQAsBAJILAQCWCwEA6gsBAOsLAQDvCwEA9gsBAE8MAQBWDAEAcgwBAHYMAQC5DAEA
wgwBAAINAQAJDQEAFA0BAB4NAQB1DgEAeA4BAN4OAQDmDgEATQ8BAFQPAQDMDwEA0w8BACEQAQAr
EAEAnxABAKUQAQDlEAEABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABsABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAQABwAEAAIABAAHAAQA
BwAEAAcAHAAHABwABwACAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAAAAAAN4AAADlAAAA+AAAAP0AAAC2BwAA4QcAAEwWAABOFgAAvxYAANsWAAAdHQAA
Oh0AANMdAADcHQAA9CAAAPYgAADEIgAAxiIAABAmAAAfJgAATicAAJYnAAD5KAAA+ygAAAotAAAS
LQAAJS4AADwuAADvLwAA8y8AAB00AAAgNAAA1ToAAOI6AAD8OgAACTsAAHxAAACHQAAAxEAAAMVA
AAD0QQAABUIAAOlDAADtQwAAY0gAAGZIAAANSwAAEUsAAElLAABNSwAAZ0sAAGtLAACqVwAAsVcA
AIdYAACIWAAATloAAFBaAAASXQAAFl0AAAteAAATXgAAz14AANdeAACUXwAAnF8AAG1hAABvYQAA
+WEAAAFiAAC8YgAAxGIAAAplAAAXZQAAMWUAAD5lAAB0cgAAeHIAAHt4AACCeAAAo3oAAL56AAAC
fAAAGXwAAI58AACXfAAAoH4AAK1+AAAifwAAMH8AACaAAAAsgAAA6YAAAO+AAAA0hgAAXIYAAK+I
AAC6iAAAOIkAAEGJAACWigAApYoAAA2LAAAeiwAAkYsAAKKLAAD9jQAAD44AAGKPAABujwAApI8A
AMqPAAA1kAAAPZAAAO6QAAATkQAAA5IAAAuSAABSkgAAWpIAAHqSAACGkgAAJZMAADaTAABNkwAA
XpMAAP+UAAAnlQAADZkAABqZAACEmQAAipkAAJiaAAChmgAA7JoAAPWaAAB0nQAAgZ0AAImfAACZ
nwAAWqAAAMKgAACFoQAAmaEAAKKhAAC2oQAAwqEAANKhAADZoQAA6aEAAPOhAAD+oQAAEaIAAByi
AAAtogAAOKIAAE+iAABaogAA5KMAAPijAAAPpAAAI6QAADikAABIpAAAZ6QAAHekAACPpAAAmqQA
AL6kAADJpAAA66QAAPakAAAepQAAKaUAANGnAADcpwAACq8AABavAACWrwAApK8AAKmyAAC5sgAA
TLMAAGCzAAB+swAAkrMAAJuzAAC4swAAubMAAM2zAADsswAAALQAAB20AAAxtAAAOrQAAE60AABQ
tAAAV7QAAH60AACStAAAobQAAMO0AADQtAAA/7QAABG1AAA+tQAAT7UAAGO1AADFtQAAz7UAAH24
AACIuAAAMb0AAEC9AABdvwAAab8AAOy/AAD6vwAAeMIAAIjCAAAAwwAAQsMAAE/DAABjwwAAcsMA
AJTDAAChwwAA0MMAAOHDAAD1wwAAtcYAAL7GAADOxwAA0McAANXHAADXxwAAz8gAANnIAABjyQAA
d8kAAObJAADuyQAAbcoAAHPKAADuygAA9soAAHXLAAB7ywAAU8wAAH7MAACczAAAn8wAAOLMAADk
zAAAhs0AAIzNAAC+zQAAxs0AAOnNAADqzQAACs4AABDOAAAszgAALc4AAC7PAAA4zwAAotAAAM3Q
AABU1AAAX9QAAG3bAAB52wAAeNwAAIjcAAAc3QAAPt0AAGPeAABu3gAAiOUAAJTlAAAU5gAAHOYA
AJvnAACr5wAAmegAALvoAADN6AAA+ugAAAzqAAAX6gAA5fEAAPHxAAD58wAACfQAAF/1AACB9QAA
kvUAAK/1AADA9QAA3fUAAPj2AAAD9wAA9f4AAAH/AAAJAQEAGQEBAH8CAQChAgEAsgIBAM8CAQDn
AgEACwMBAIYHAQCJBwEAyAgBANYIAQAZCgEAGwoBAN4KAQDeCgEA3woBAN8KAQDgCgEA4AoBAOEK
AQDiCgEA4woBAOQKAQDqCwEA6wsBAMcMAQDJDAEAywwBAM0MAQB1DgEA2Q4BAFkQAQBdEAEA5RAB
AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH
ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz
AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH
ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz
AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH
ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcABAAHAAQAAgAEAAcABAAHAAQABwACAAcAMwAHADMABwAzAAcAMwAHAAAAAAB0
AAAAewAAAIoAAACRAAAAngAAAKQAAAD3CAAACQkAAAoJAAAZCQAA2woAAPUKAAA6DAAAVQwAAHFD
AACkQwAApEQAANZEAABuUwAAi1MAAG5VAACIVQAAel0AAPxdAAA9XgAAfl4AAARgAABFYAAACGEA
AElhAABNYgAAjmIAALNqAADlagAAqm8AAN5vAACGcgAACnMAAOB1AAApdwAAKncAAGx3AACudwAA
8HcAAGl6AACMegAAyXoAAAZ7AAANfgAAkH4AABF/AADVfwAAVoAAALKAAADqhAAAAoUAAFOHAACC
hwAAZogAAN+IAAALigAAFYoAABWRAABykQAAi5YAAIyWAADElwAA1ZcAAC+ZAADGmQAA/J4AAGCf
AABQpQAAa6UAAKamAACtpgAAIaoAAGOqAAClqgAA56oAAGi1AACDtQAAUbsAAJO7AABZvAAAnLwA
ACfBAADswQAA7cEAAHLCAABExwAAaccAANXHAADbxwAA6ssAAA/MAAAg1gAAJ9cAACjXAABz2AAA
CtoAABHaAACr2wAActwAADfhAAA+4gAAP+IAAILiAAAZ5AAAIOQAAFLnAACV5wAA/egAABnpAADY
6wAAK+4AAIbwAACN8AAAr/MAAPPzAADE+AAAF/sAAIb9AACN/QAAvwABAAMBAQAOAwEAJgMBAHID
AQCOAwEALgQBAEUEAQCNBQEAmgUBANsGAQD4BgEA3goBAN4KAQDfCgEA3woBAOAKAQDgCgEA4QoB
AOIKAQDjCgEA5AoBAEkLAQBYCwEA5gsBAOgLAQDqCwEA6wsBAOUQAQAHAAUABwAFAAcABQAHAAUA
BwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH
AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA
BAAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAF
AAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUA
BwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABAAHAAQAAgAEAAcABAAHAAQABwADAAcABQAH
AAIABwD//xQAAAAGAGoAawBjAGgAbwBpAEYARgA6AFwAagBrAGMAaABvAGkAMQBcADIAMAAwADAA
/KwcyFwATQBQAEwAUwAEx8HQXABkAHIAYQBmAHQAkccxwVwAZAByAGEAZgB0AC0AYwBoAG8AaQAt
AG0AbwBiAGkAbABlAGkAcAAtAGwAZABwAGUAeAB0AC0AMAAwAC4AdAB4AHQALgBEAE8AQwAGAGoA
awBjAGgAbwBpAEYARgA6AFwAagBrAGMAaABvAGkAMQBcADIAMAAwADAA/KwcyFwATQBQAEwAUwAE
x8HQXABkAHIAYQBmAHQAkccxwVwAZAByAGEAZgB0AC0AYwBoAG8AaQAtAG0AbwBiAGkAbABlAGkA
cAAtAGwAZABwAGUAeAB0AC0AMAAwAC4AdAB4AHQALgBEAE8AQwAGAGoAawBjAGgAbwBpAGoAQwA6
AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAGoAawBjAGgA
bwBpAFwAQQBwAHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0
AFwAVwBvAHIAZABcAJDH2bMgAPW8bK0gAADIpcdkAHIAYQBmAHQALQBjAGgAbwBpAC0AbQBvAGIA
aQBsAGUAaQBwAC0AbABkAHAAZQB4AHQALQAwADAALgBhAHMAZAAGAGoAawBjAGgAbwBpAGoAQwA6
AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAGoAawBjAGgA
bwBpAFwAQQBwAHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0
AFwAVwBvAHIAZABcAJDH2bMgAPW8bK0gAADIpcdkAHIAYQBmAHQALQBjAGgAbwBpAC0AbQBvAGIA
aQBsAGUAaQBwAC0AbABkAHAAZQB4AHQALQAwADAALgBhAHMAZAAGAGoAawBjAGgAbwBpAEYARgA6
AFwAagBrAGMAaABvAGkAMQBcADIAMAAwADAA/KwcyFwATQBQAEwAUwAEx8HQXABkAHIAYQBmAHQA
kccxwVwAZAByAGEAZgB0AC0AYwBoAG8AaQAtAG0AbwBiAGkAbABlAGkAcAAtAGwAZABwAGUAeAB0
AC0AMAAwAC4AdAB4AHQALgBEAE8AQwAGAGoAawBjAGgAbwBpAGoAQwA6AFwARABvAGMAdQBtAGUA
bgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAGoAawBjAGgAbwBpAFwAQQBwAHAAbABp
AGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABcAJDH
2bMgAPW8bK0gAADIpcdkAHIAYQBmAHQALQBjAGgAbwBpAC0AbQBvAGIAaQBsAGUAaQBwAC0AbABk
AHAAZQB4AHQALQAwADAALgBhAHMAZAAGAGoAawBjAGgAbwBpAGoAQwA6AFwARABvAGMAdQBtAGUA
bgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAGoAawBjAGgAbwBpAFwAQQBwAHAAbABp
AGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABcAJDH
2bMgAPW8bK0gAADIpcdkAHIAYQBmAHQALQBjAGgAbwBpAC0AbQBvAGIAaQBsAGUAaQBwAC0AbABk
AHAAZQB4AHQALQAwADAALgBhAHMAZAAGAGoAawBjAGgAbwBpAGoAQwA6AFwARABvAGMAdQBtAGUA
bgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAGoAawBjAGgAbwBpAFwAQQBwAHAAbABp
AGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABcAJDH
2bMgAPW8bK0gAADIpcdkAHIAYQBmAHQALQBjAGgAbwBpAC0AbQBvAGIAaQBsAGUAaQBwAC0AbABk
AHAAZQB4AHQALQAwADAALgBhAHMAZAAGAGoAawBjAGgAbwBpAEYARgA6AFwAagBrAGMAaABvAGkA
MQBcADIAMAAwADAA/KwcyFwATQBQAEwAUwAEx8HQXABkAHIAYQBmAHQAkccxwVwAZAByAGEAZgB0
AC0AYwBoAG8AaQAtAG0AbwBiAGkAbABlAGkAcAAtAGwAZABwAGUAeAB0AC0AMAAwAC4AdAB4AHQA
LgBEAE8AQwAGAGoAawBjAGgAbwBpAGoAQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAg
AFMAZQB0AHQAaQBuAGcAcwBcAGoAawBjAGgAbwBpAFwAQQBwAHAAbABpAGMAYQB0AGkAbwBuACAA
RABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABcAJDH2bMgAPW8bK0gAADIpcdk
AHIAYQBmAHQALQBjAGgAbwBpAC0AbQBvAGIAaQBsAGUAaQBwAC0AbABkAHAAZQB4AHQALQAwADAA
LgBhAHMAZAAhAHz///9E1AhAQAD/D/8P/w//D/8P/w//D/8PAQB9////+iXKkz8A/w//D/8P/w//
D/8P/w//DwEAfv///85zEqM+AP8P/w//D/8P/w//D/8P/w8BAH////9aSK57PQD/D/8P/w//D/8P
/w//D/8PAQCA////dCvgdCIA/w//D/8P/w//D/8P/w//DwEAgf///25AmtAhAP8P/w//D/8P/w//
D/8P/w8BAIL///9MWwguIAD/D/8P/w//D/8P/w//D/8PAQCD////OJ1gpx8A/w//D/8P/w//D/8P
/w//DwEAiP///5Z0gog8AP8P/w//D/8P/w//D/8P/w8BAIn////2n/ZeHgD/D/8P/w//D/8P/w//
D/8PAQAZS2cCVr3yef8P/w//D/8P/w//D/8P/w//DxAAHT7cA1QT+hH/D/8P/w//D/8P/w//D/8P
/w8QANd/OgqQY2ZP/w//D/8P/w//D/8P/w//D/8PAAC8D9sOlhFcrf8P/w//D/8P/w//D/8P/w//
DwAAO0NhElCsAtn/D/8P/w//D/8P/w//D/8P/w8QAKNMhCIXAAkE/w//D/8P/w//D/8P/w//D/8P
AQBbadUjMn7WUP8P/w//D/8P/w//D/8P/w//DxAAlTKpJDiOJgf/D/8P/w//D/8P/w//D/8P/w8Q
ANkWNCsPAAkE/w//D/8P/w//D/8P/w//D/8PAQCkddkuaqzepf8P/w//D/8P/w//D/8P/w//DxAA
YyEqMw8ACQT/DwAAAAAAAAAAAAAAAAAAAAABAAdCyzOav5hB/w//D/8P/w//D/8P/w//D/8PAAC1
aWlGDwAJBP8P/w//D/8P/w//D/8P/w//DwEA8w5BTJ5w1mj/D/8P/w//D/8P/w//D/8P/w8BABwB
0U24m77x/w//D/8P/w//D/8P/w//D/8PEACxGxhP8izEO/8P/w//D/8P/w//D/8P/w//DwEA+i3l
UAEACQT/DwAAAAAAAAAAAAAAAAAAAAABAEcc0lWs/qj+/w//D/8P/w//D/8P/w//D/8PAQA/HeRp
0IOcK/8P/w//D/8P/w//D/8P/w//DxAANy8PcEQZjCb/D/8P/w//D/8P/w//D/8P/w8BAP53+3nC
e85W/w//D/8P/w//D/8P/w//D/8PAQDcB9V6DwAJBP8PAAAAAAAAAAAAAAAAAAAAAAEA9Hj8eg8A
CQT/DwAAAAAAAAAAAAAAAAAAAAABAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAgAAAPhA4IEYSY
/hXGBQABDggGVkToA1dEOP9ehA4IYISY/gIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAg
AAAPhGUGEYSY/hXGBQABZQYGVkQgA1dEOP9ehGUGYISY/gIAAAAuAAEAAAAAAAEAAAAAAAAAAAAA
AAAAAAAAAAAgAAAPhLwEEYSY/hXGBQABvAQGVkRYAldEOP9ehLwEYISY/gIAAAAuAAEAAAAAAAEA
AAAAAAAAAAAAAAAAAAAAAAAgAAAPhBIDEYSY/hXGBQABEgMGVkSQAVdEOP9ehBIDYISY/gIAAAAu
AAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsgAAAPhA4IEYSY/hXGBQABDggGVkToA1dEOP9ehA4I
YISY/k9KCQBRSgkAbygAAQBs8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsgAAAPhGUGEYSY/hXG
BQABZQYGVkQgA1dEOP9ehGUGYISY/k9KCQBRSgkAbygAAQBs8AEAAAAXAAAAAAAAAAAAAAAAAAAA
AAAAAAsgAAAPhLwEEYSY/hXGBQABvAQGVkRYAldEOP9ehLwEYISY/k9KCQBRSgkAbygAAQBs8AEA
AAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsgAAAPhBIDEYSY/hXGBQABEgMGVkSQAVdEOP9ehBIDYISY
/k9KCQBRSgkAbygAAQBs8AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAgAAAPhGkBEYSY/hXGBQAB
aQEGVkTIAFdEOP9ehGkBYISY/gIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsgAAAPhGkB
EYSY/hXGBQABaQEGVkTIAFdEOP9ehGkBYISY/k9KCQBRSgkAbygAAQBs8AMAAAAXAAAAAAAAAAAA
AAAAAAAAAAAAABMYAAAPhPgCEYSY/hXGBQAB+AIGXoT4AmCEmP5PSgAAUEoFAFFKAABeSgAAbygA
AQAtAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhLAEEYRw/hXGBQABsAQGXoSwBGCEcP5P
SgkAUUoJAG8oAAEAbvABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RABhGEcP4VxgUAAUAG
Bl6EQAZghHD+T0oJAFFKCQBvKAABAHXwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E0AcR
hHD+FcYFAAHQBwZehNAHYIRw/k9KCQBRSgkAbygAAQBs8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAA
AAsYAAAPhGAJEYRw/hXGBQABYAkGXoRgCWCEcP5PSgkAUUoJAG8oAAEAbvABAAAAF4AAAAAAAAAA
AAAAAAAAAAAAAAALGAAAD4TwChGEcP4VxgUAAfAKBl6E8ApghHD+T0oJAFFKCQBvKAABAHXwAQAA
ABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EgAwRhHD+FcYFAAGADAZehIAMYIRw/k9KCQBRSgkA
bygAAQBs8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhBAOEYRw/hXGBQABEA4GXoQQDmCE
cP5PSgkAUUoJAG8oAAEAbvABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SgDxGEcP4VxgUA
AaAPBl6EoA9ghHD+T0oJAFFKCQBvKAABAHXwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E
GAMRhJj+FcYFAAEYAwZehBgDYISY/m8oAQIAAAApAAEAAAADgAEAAAAAAAAAAAAAAAAAAAAAAAAY
AAAPhNAEEYRw/hXGBQAB0AQGXoTQBGCEcP4CAAEALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAA
GAAAD4RgBhGEcP4VxgUAAWAGBl6EYAZghHD+AgACAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAA
ABgAAA+E8AcRhHD+FcYFAAHwBwZehPAHYIRw/gIAAwAuAAEAAAADgAEAAAAAAAAAAAAAAAAAAAAA
AAAYAAAPhIAJEYRw/hXGBQABgAkGXoSACWCEcP4CAAQALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAA
AAAAGAAAD4QQCxGEcP4VxgUAARALBl6EEAtghHD+AgAFAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAA
AAAAABgAAA+EoAwRhHD+FcYFAAGgDAZehKAMYIRw/gIABgAuAAEAAAADgAEAAAAAAAAAAAAAAAAA
AAAAAAAYAAAPhDAOEYRw/hXGBQABMA4GXoQwDmCEcP4CAAcALgABAAAAAoIBAAAAAAAAAAAAAAAA
AAAAAAAAGAAAD4TADxGEcP4VxgUAAcAPBl6EwA9ghHD+AgAIAC4ABQAAAAAAAQAAAAAAAAAAAAAA
AAAAAAAAAxgAAA+E0AIRhDD9FcYFAAHQAgZehNACYIQw/W8oAAEAAAABAAAAAAABAwAAAAAAAAAA
AAAAAAAAAAADGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9bygAAwAAAC4AAQABAAAAAAABAwUA
AAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9bygABQAAAC4AAQAuAAIA
AQAAAAAAAQMFBwAAAAAAAAAAAAAAAAAAAxgAAA+EOAQRhMj7FcYFAAE4BAZehDgEYITI+28oAAcA
AAAuAAEALgACAC4AAwABAAAAAAABAwUHCQAAAAAAAAAAAAAAAAADGAAAD4Q4BBGEyPsVxgUAATgE
Bl6EOARghMj7bygACQAAAC4AAQAuAAIALgADAC4ABAABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAAD
GAAAD4SgBRGEYPoVxgUAAaAFBl6EoAVghGD6bygACwAAAC4AAQAuAAIALgADAC4ABAAuAAUAAQAA
AAAAAQMFBwkLDQAAAAAAAAAAAAAAAxgAAA+ECAcRhPj4FcYFAAEIBwZehAgHYIT4+G8oAA0AAAAu
AAEALgACAC4AAwAuAAQALgAFAC4ABgABAAAAAAABAwUHCQsNDwAAAAAAAAAAAAADGAAAD4QIBxGE
+PgVxgUAAQgHBl6ECAdghPj4bygADwAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwABAAAA
AAABAwUHCQsNDxEAAAAAAAAAAAADGAAAD4RwCBGEkPcVxgUAAXAIBl6EcAhghJD3bygAEQAAAC4A
AQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgABAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxgA
AA+EaAERhJj+FcYFAAFoAQZehGgBYISY/m8oAAIAAAAuAAEAAAAABAEDAAAAAAAAAAAAAAAAAAAA
AAMYAAAPhNACEYQw/RXGBQAB0AIGXoTQAmCEMP1vKAAEAAAALgABAC4AAQAAAAAEAQMFAAAAAAAA
AAAAAAAAAAAAAxgAAA+E0AIRhDD9FcYFAAHQAgZehNACYIQw/W8oAAYAAAAuAAEALgACAC4AAQAA
AAAEAQMFBwAAAAAAAAAAAAAAAAAAAxgAAA+EOAQRhMj7FcYFAAE4BAZehDgEYITI+28oAAgAAAAu
AAEALgACAC4AAwAuAAEAAAAABAEDBQcJAAAAAAAAAAAAAAAAAAMYAAAPhKAFEYRg+hXGBQABoAUG
XoSgBWCEYPpvKAAKAAAALgABAC4AAgAuAAMALgAEAC4AAQAAAAAEAQMFBwkLAAAAAAAAAAAAAAAA
AxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+m8oAAwAAAAuAAEALgACAC4AAwAuAAQALgAFAC4A
AQAAAAAEAQMFBwkLDQAAAAAAAAAAAAAAAxgAAA+ECAcRhPj4FcYFAAEIBwZehAgHYIT4+G8oAA4A
AAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAEAAAAABAEDBQcJCw0PAAAAAAAAAAAAAAMYAAAP
hHAIEYSQ9xXGBQABcAgGXoRwCGCEkPdvKAAQAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAH
AC4AAQAAAAAEAQMFBwkLDQ8RAAAAAAAAAAAAAxgAAA+EcAgRhJD3FcYFAAFwCAZehHAIYISQ928o
ABIAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAC4AAQAAAAAAAQAAAAAAAAAAAAAA
AAAAAAAAABgAAA+EIAMRhHD+FcYFAAEgAwZehCADYIRw/gIAAAAuAAEAAAADgAEAAAAAAAAAAAAA
AAAAAAAAAAAYAAAPhLAEEYRw/hXGBQABsAQGXoSwBGCEcP4CAAEALgABAAAAAoIBAAAAAAAAAAAA
AAAAAAAAAAAAGAAAD4RABhGEcP4VxgUAAUAGBl6EQAZghHD+AgACAC4AAQAAAACAAQAAAAAAAAAA
AAAAAAAAAAAAABgAAA+E0AcRhHD+FcYFAAHQBwZehNAHYIRw/gIAAwAuAAEAAAADgAEAAAAAAAAA
AAAAAAAAAAAAAAAYAAAPhGAJEYRw/hXGBQABYAkGXoRgCWCEcP4CAAQALgABAAAAAoIBAAAAAAAA
AAAAAAAAAAAAAAAAGAAAD4TwChGEcP4VxgUAAfAKBl6E8ApghHD+AgAFAC4AAQAAAACAAQAAAAAA
AAAAAAAAAAAAAAAAABgAAA+EgAwRhHD+FcYFAAGADAZehIAMYIRw/gIABgAuAAEAAAADgAEAAAAA
AAAAAAAAAAAAAAAAAAAYAAAPhBAOEYRw/hXGBQABEA4GXoQQDmCEcP4CAAcALgABAAAAAoIBAAAA
AAAAAAAAAAAAAAAAAAAAGAAAD4SgDxGEcP4VxgUAAaAPBl6EoA9ghHD+AgAIAC4AAQAAAAQAAQAA
AAAAAAAAAAAAAAAAAAAAAxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/m8oAAIAAAApAAEAAAAA
AAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhEMDEYRN/hXGBQABQwMGXoRDA2CETf5vKAECAAAALgAB
AAAAA4ABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SwBBGEcP4VxgUAAbAEBl6EsARghHD+AgABAC4A
AQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EQAYRhHD+FcYFAAFABgZehEAGYIRw/gIAAgAu
AAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhNAHEYRw/hXGBQAB0AcGXoTQB2CEcP4CAAMA
LgABAAAAA4ABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RgCRGEcP4VxgUAAWAJBl6EYAlghHD+AgAE
AC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E8AoRhHD+FcYFAAHwCgZehPAKYIRw/gIA
BQAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhIAMEYRw/hXGBQABgAwGXoSADGCEcP4C
AAYALgABAAAAA4ABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QQDhGEcP4VxgUAARAOBl6EEA5ghHD+
AgAHAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EoA8RhHD+FcYFAAGgDwZehKAPYIRw
/gIACAAuAAAAAAAXAAAAAAAAAAAAAAAAAAAAAAAAABMYAAAPhPgCEYSY/hXGBQAB+AIGXoT4AmCE
mP5PSgAAUEoFAFFKAABeSgAAbygAAQAtAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhLAE
EYRw/hXGBQABsAQGXoSwBGCEcP5PSgkAUUoJAG8oAAEAbvABAAAAF4AAAAAAAAAAAAAAAAAAAAAA
AAALGAAAD4RABhGEcP4VxgUAAUAGBl6EQAZghHD+T0oJAFFKCQBvKAABAHXwAQAAABeAAAAAAAAA
AAAAAAAAAAAAAAAACxgAAA+E0AcRhHD+FcYFAAHQBwZehNAHYIRw/k9KCQBRSgkAbygAAQBs8AEA
AAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGAJEYRw/hXGBQABYAkGXoRgCWCEcP5PSgkAUUoJ
AG8oAAEAbvABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4TwChGEcP4VxgUAAfAKBl6E8Apg
hHD+T0oJAFFKCQBvKAABAHXwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EgAwRhHD+FcYF
AAGADAZehIAMYIRw/k9KCQBRSgkAbygAAQBs8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAP
hBAOEYRw/hXGBQABEA4GXoQQDmCEcP5PSgkAUUoJAG8oAAEAbvABAAAAF4AAAAAAAAAAAAAAAAAA
AAAAAAALGAAAD4SgDxGEcP4VxgUAAaAPBl6EoA9ghHD+T0oJAFFKCQBvKAABAHXwAwAAAAAAAQAA
AAAAAAAAAAAAAAAAAAAAAxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/m8oAAIAAAAuAAEAAAAE
AAIAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhGAEEYQw/RXGBQABYAQGXoRgBGCEMP1vKAEDACgAAAAp
AAEAAAADgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhLAEEYRw/hXGBQABsAQGXoSwBGCEcP4CAAEA
LgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RABhGEcP4VxgUAAUAGBl6EQAZghHD+AgAC
AC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E0AcRhHD+FcYFAAHQBwZehNAHYIRw/gIA
AwAuAAEAAAADgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhGAJEYRw/hXGBQABYAkGXoRgCWCEcP4C
AAQALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4TwChGEcP4VxgUAAfAKBl6E8ApghHD+
AgAFAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EgAwRhHD+FcYFAAGADAZehIAMYIRw
/gIABgAuAAEAAAADgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhBAOEYRw/hXGBQABEA4GXoQQDmCE
cP4CAAcALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SgDxGEcP4VxgUAAaAPBl6EoA9g
hHD+AgAIAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EaAERhJj+FcYFAAFoAQZehGgB
YISY/gIAAAAuAAUAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB0AIGXoTQ
AmCEMP1vKAACAAAALgABAAAAAAQBAwAAAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEMP0VxgUAAdAC
Bl6E0AJghDD9bygABAAAAC4AAQAuAAEAAAAABAEDBQAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw
/RXGBQAB0AIGXoTQAmCEMP1vKAAGAAAALgABAC4AAgAuAAEAAAAABAEDBQcAAAAAAAAAAAAAAAAA
AAMYAAAPhDgEEYTI+xXGBQABOAQGXoQ4BGCEyPtvKAAIAAAALgABAC4AAgAuAAMALgABAAAAAAQB
AwUHCQAAAAAAAAAAAAAAAAADGAAAD4SgBRGEYPoVxgUAAaAFBl6EoAVghGD6bygACgAAAC4AAQAu
AAIALgADAC4ABAAuAAEAAAAABAEDBQcJCwAAAAAAAAAAAAAAAAMYAAAPhKAFEYRg+hXGBQABoAUG
XoSgBWCEYPpvKAAMAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAEAAAAABAEDBQcJCw0AAAAAAAAA
AAAAAAMYAAAPhAgHEYT4+BXGBQABCAcGXoQIB2CE+PhvKAAOAAAALgABAC4AAgAuAAMALgAEAC4A
BQAuAAYALgABAAAAAAQBAwUHCQsNDwAAAAAAAAAAAAADGAAAD4RwCBGEkPcVxgUAAXAIBl6EcAhg
hJD3bygAEAAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAEAAAAABAEDBQcJCw0PEQAA
AAAAAAAAAAMYAAAPhHAIEYSQ9xXGBQABcAgGXoRwCGCEkPdvKAASAAAALgABAC4AAgAuAAMALgAE
AC4ABQAuAAYALgAHAC4ACAAuAAMAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhGgBEYSY/hXG
BQABaAEGXoRoAWCEmP5vKAACAAAALgADAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4RYAhGE
qP0VxgUAAVgCBl6EWAJghKj9bygAAgAAAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E
+AIRhJj+FcYFAAH4AgZehPgCYISY/m8oAQIAAAAuAAEAAAAABAEDAAAAAAAAAAAAAAAAAAAAAAMY
AAAPhPgCEYSY/hXGBQAB+AIGXoT4AmCEmP5vKAEDAAAALgABAAEAAAAABAEDBQAAAAAAAAAAAAAA
AAAAAAMYAAAPhGAEEYQw/RXGBQABYAQGXoRgBGCEMP1vKAEFAAAALgABAC4AAgABAAAAAAQBAwUH
AAAAAAAAAAAAAAAAAAADGAAAD4RgBBGEMP0VxgUAAWAEBl6EYARghDD9bygBBwAAAC4AAQAuAAIA
LgADAAEAAAAABAEDBQcJAAAAAAAAAAAAAAAAAAMYAAAPhMgFEYTI+xXGBQAByAUGXoTIBWCEyPtv
KAEJAAAALgABAC4AAgAuAAMALgAEAAEAAAAABAEDBQcJCwAAAAAAAAAAAAAAAAMYAAAPhMgFEYTI
+xXGBQAByAUGXoTIBWCEyPtvKAELAAAALgABAC4AAgAuAAMALgAEAC4ABQABAAAAAAQBAwUHCQsN
AAAAAAAAAAAAAAADGAAAD4QwBxGEYPoVxgUAATAHBl6EMAdghGD6bygBDQAAAC4AAQAuAAIALgAD
AC4ABAAuAAUALgAGAAEAAAAABAEDBQcJCw0PAAAAAAAAAAAAAAMYAAAPhDAHEYRg+hXGBQABMAcG
XoQwB2CEYPpvKAEPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAAEAAAAABAEDBQcJCw0P
EQAAAAAAAAAAAAMYAAAPhJgIEYT4+BXGBQABmAgGXoSYCGCE+PhvKAERAAAALgABAC4AAgAuAAMA
LgAEAC4ABQAuAAYALgAHAC4ACAABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4QYAxGEmP4V
xgUAARgDBl6EGANghJj+bygAAgAAACkAAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EaAER
hJj+FcYFAAFoAQZehGgBYISY/k9KAQBRSgEAbygAAQC38AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAA
AAMYAAAPhGADEYRQ/hXGBQABYAMGXoRgA2CEUP5vKAACAAAAKQABAAAABAACAAAAAAAAAAAAAAAA
AAAAAAADGAAAD4RgBBGEMP0VxgUAAWAEBl6EYARghDD9bygBAwAoAAAAKQABAAAAA4ABAAAAAAAA
AAAAAAAAAAAAAAAAGAAAD4SwBBGEcP4VxgUAAbAEBl6EsARghHD+AgABAC4AAQAAAAKCAQAAAAAA
AAAAAAAAAAAAAAAAABgAAA+EQAYRhHD+FcYFAAFABgZehEAGYIRw/gIAAgAuAAEAAAAAgAEAAAAA
AAAAAAAAAAAAAAAAAAAYAAAPhNAHEYRw/hXGBQAB0AcGXoTQB2CEcP4CAAMALgABAAAAA4ABAAAA
AAAAAAAAAAAAAAAAAAAAGAAAD4RgCRGEcP4VxgUAAWAJBl6EYAlghHD+AgAEAC4AAQAAAAKCAQAA
AAAAAAAAAAAAAAAAAAAAABgAAA+E8AoRhHD+FcYFAAHwCgZehPAKYIRw/gIABQAuAAEAAAAAgAEA
AAAAAAAAAAAAAAAAAAAAAAAYAAAPhIAMEYRw/hXGBQABgAwGXoSADGCEcP4CAAYALgABAAAAA4AB
AAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QQDhGEcP4VxgUAARAOBl6EEA5ghHD+AgAHAC4AAQAAAAKC
AQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EoA8RhHD+FcYFAAGgDwZehKAPYIRw/gIACAAuAAYAAAAA
AAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhFgCEYSo/RXGBQABWAIGXoRYAmCEqP1vKAACAAAALgAK
AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9bygAAgAA
AC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/gIA
AAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP4C
AAAALgAhAAAAo0yEIgAAAAAAAAAAAAAAAPot5VAAAAAAAAAAAAAAAADzDkFMAAAAAAAAAAAAAAAA
Ny8PcAAAAAAAAAAAAAAAANkWNCsAAAAAAAAAAAAAAAC1aWlGAAAAAAAAAAAAAAAAB0LLMwAAAAAA
AAAAAAAAANd/OgoAAAAAAAAAAAAAAAC8D9sOAAAAAAAAAAAAAAAA/nf7eQAAAAAAAAAAAAAAAEcc
0lUAAAAAAAAAAAAAAACxGxhPAAAAAAAAAAAAAAAA9Hj8egAAAAAAAAAAAAAAAGMhKjMAAAAAAAAA
AAAAAADcB9V6AAAAAAAAAAAAAAAAGUtnAgAAAAAAAAAAAAAAAB0+3AMAAAAAAAAAAAAAAAA/HeRp
AAAAAAAAAAAAAAAAW2nVIwAAAAAAAAAAAAAAAKR12S4AAAAAAAAAAAAAAACJ////AAAAAAAAAAAA
AAAAgf///wAAAAAAAAAAAAAAAJUyqSQAAAAAAAAAAAAAAAAcAdFNAAAAAAAAAAAAAAAAg////wAA
AAAAAAAAAAAAAIL///8AAAAAAAAAAAAAAACA////AAAAAAAAAAAAAAAAiP///wAAAAAAAAAAAAAA
AH////8AAAAAAAAAAAAAAAB+////AAAAAAAAAAAAAAAAff///wAAAAAAAAAAAAAAAHz///8AAAAA
AAAAAAAAAAA7Q2ESAAAAAAAAAAAAAAAA////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////8hAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
//8hAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAN4bZrwDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQD
AAkEBQAJBBIA9uMCZhkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEAAAAABIADwAJBBkA
CQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEAAASALrRzDQZAAkEGwAJBA8ACQQZAAkEGwAJ
BA8ACQQZAAkEGwAJBBIAflcqYgMACQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEAAASAJSP
qOQZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBAAAAAAAAAAAEgD/////////////////
//////////////////////////////8AAAAAAAASADSqMs0ZAAkEGwAJBA8ACQQZAAkEGwAJBA8A
CQQZAAkEGwAJBAAAAAAAAAAAAQAAAAEACQQFAAIAQAAAAAAAEwAAACEAAAAiAAAAMQAAADYAAAA3
AAAAYwAAAHIAAABzAAAAdAAAAHkAAAB6AAAAewAAAIgAAACJAAAAigAAAI8AAACQAAAAkQAAAJwA
AACdAAAAngAAAKMAAACkAAAApQAAALQAAAC1AAAA3goBAN8KAQDhCgEA4woBAOYLAQDpCwEA6wsB
AEsMAQDHDwEA4RABAOUQAQAAAAAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAA
AgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACe
AQAAAgEAAAIBAACWAQAAAAAAAAEAAAABAAAAAQAAAAEAAAABAAAAAAAAAAEAAAABAAAAAQAAAP9A
DIABAAAAAAAAAAAAOPTfAAEAAQAAAAAAAAAAAAAAAAAAAAAAAhAAAAAAAAAA5BABAEAAAAgAQAAA
//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAA
AP//AAACAP//AAAAAAoAAABHFpABAAACAgYDBQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAA
VABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAA
AAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAA
AAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAPzWQAQAAAgcDCQICBQIEBId6ACAAAACACAAAAAAAAAD/
AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAAC8VkAGBAAIDBgkAAQEBAQGvAgCw+3zXaTAA
AAAAAAAAnwAIAAAAAAAUvNXQtMwAADsWkAGBAwIDBgAAAQEBAQGvAgCw+3zXaTAAAAAAAAAAnwAI
AAAAAAAUvNXQAABCAGEAdABhAG4AZwAAADkxkAGBAwILBgAAAQEBAQEBAAAAAAAGCRAAAAAAAAAA
AAAIAAAAAADLs8DGAABEAG8AdAB1AG0AAAA1JpABAAACCwYEAwUEBAIEh3oAIQAAAIAIAAAAAAAA
AP8BAQAAAAAAVABhAGgAbwBtAGEAAABJNpABgQACCwYEAgICAgIE/////////+k/AAAAAAAAAP8A
HwAAAAAAQQByAGkAYQBsACAAVQBuAGkAYwBvAGQAZQAgAE0AUwAAADsGkAECAAUAAAAAAAAAAAAA
AAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBnAGQAaQBuAGcAcwAAACIABAAxCIgYAPCABAAA
aAEAAAAAh4VLhpSIS6ahhEuGRgDmAAAAmiYAAAzcAAABAHAAAAAEAIAQ1QEAAAAAAAAAAAAAAQAB
AAAAAQAAAAAAAAAhgwDwEAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAEjAA
ABAAGQBkAAAAGQAAADsOAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwyg1EA8BAE3wMAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAAFQBOAGUAdAB3AG8AcgBrACAAVwBvAHIAawBpAG4A
ZwAgAEcAcgBvAHUAcAAAAAAAAAALAE0AaQBrAGUAIABHAGEAaAByAG4AcwAGAGoAawBjAGgAbwBp
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5
T2gQq5EIACsns9kwAAAAkAEAABIAAAABAAAAmAAAAAIAAACgAAAAAwAAAMAAAAAEAAAAzAAAAAUA
AADgAAAABgAAAOwAAAAHAAAA+AAAAAgAAAAIAQAACQAAABgBAAASAAAAJAEAAAoAAABAAQAACwAA
AEwBAAAMAAAAWAEAAA0AAABkAQAADgAAAHABAAAPAAAAeAEAABAAAACAAQAAEwAAAIgBAAACAAAA
tQMAAB4AAAAWAAAATmV0d29yayBXb3JraW5nIEdyb3VwADkAHgAAAAEAAAAAZXR3HgAAAAwAAABN
aWtlIEdhaHJucwAeAAAAAQAAAABpa2UeAAAAAQAAAABpa2UeAAAABwAAAE5vcm1hbABoHgAAAAcA
AABqa2Nob2kAaB4AAAADAAAANzAAaB4AAAATAAAATWljcm9zb2Z0IFdvcmQgOS4wAHVAAAAAAORw
ISAAAABAAAAAAO6wNbBPwAFAAAAAAHLtGs5PwAFAAAAAAKDpcvFPwAEDAAAAAQAAAAMAAACaJgAA
AwAAAAzcAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAAr
LPmuMAAAAPwAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAAB8AAAABgAAAIQAAAARAAAAjAAAABcA
AACUAAAACwAAAJwAAAAQAAAApAAAABMAAACsAAAAFgAAALQAAAANAAAAvAAAAAwAAADeAAAAAgAA
ALUDAAAeAAAAAgAAACAAcgADAAAA1QEAAAMAAABwAAAAAwAAADsOAQADAAAA/AoJAAsAAAAAAAAA
CwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAWAAAATmV0d29yayBXb3JraW5nIEdyb3Vw
AAwQAAACAAAAHgAAAAUAAADBprjxAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAAN
AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsA
AAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAA
ACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAA
OAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABG
AAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQA
AABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAA
AGMAAABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAA
cQAAAHIAAABzAAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAAAH4AAAB/
AAAAgAAAAIEAAACCAAAAgwAAAIQAAACFAAAAhgAAAIcAAACIAAAAiQAAAIoAAACLAAAAjAAAAI0A
AACOAAAAjwAAAJAAAACRAAAAkgAAAJMAAACUAAAAlQAAAJYAAACXAAAAmAAAAJkAAACaAAAAmwAA
AJwAAACdAAAAngAAAJ8AAACgAAAAoQAAAKIAAACjAAAApAAAAKUAAACmAAAApwAAAKgAAACpAAAA
qgAAAKsAAACsAAAArQAAAK4AAACvAAAAsAAAALEAAACyAAAAswAAALQAAAC1AAAAtgAAALcAAAC4
AAAAuQAAALoAAAC7AAAAvAAAAL0AAAC+AAAAvwAAAMAAAADBAAAAwgAAAMMAAADEAAAAxQAAAMYA
AADHAAAAyAAAAMkAAADKAAAAywAAAMwAAADNAAAAzgAAAM8AAADQAAAA0QAAANIAAADTAAAA/v//
/9UAAADWAAAA1wAAANgAAADZAAAA2gAAANsAAADcAAAA3QAAAN4AAADfAAAA4AAAAOEAAADiAAAA
4wAAAOQAAADlAAAA5gAAAOcAAADoAAAA6QAAAOoAAADrAAAA7AAAAO0AAADuAAAA7wAAAPAAAADx
AAAA8gAAAPMAAAD0AAAA9QAAAPYAAAD3AAAA+AAAAPkAAAD6AAAA+wAAAPwAAAD9AAAA/gAAAP8A
AAAAAQAAAQEAAAIBAAADAQAABAEAAAUBAAAGAQAABwEAAAgBAAAJAQAACgEAAAsBAAAMAQAADQEA
AA4BAAAPAQAAEAEAABEBAAASAQAAEwEAABQBAAAVAQAAFgEAABcBAAAYAQAAGQEAABoBAAAbAQAA
HAEAAB0BAAAeAQAAHwEAACABAAAhAQAAIgEAACMBAAAkAQAAJQEAACYBAAAnAQAAKAEAACkBAAAq
AQAAKwEAACwBAAAtAQAALgEAAC8BAAAwAQAAMQEAADIBAAAzAQAANAEAADUBAAA2AQAANwEAADgB
AAA5AQAAOgEAADsBAAA8AQAA/v///z4BAAA/AQAAQAEAAEEBAABCAQAAQwEAAEQBAAD+////RgEA
AEcBAABIAQAASQEAAEoBAABLAQAATAEAAP7////9/////f////3///9RAQAA/v////7////+////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAACQ
P0ST8U/AAVMBAACAAAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIA////////////////AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAA1AAAAFLRAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEFAAAA//////////8A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWqYBAAAAAAAFAFMAdQBtAG0A
YQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAC
AQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD0BAAAAEAAA
AAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBu
AAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAARQEAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZgAAAAAAAABPAGIAagBlAGMAdABQAG8AbwBsAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABAP///////////////wAA
AAAAAAAAAAAAAAAAAAAAAAAAkD9Ek/FPwAGQP0ST8U/AAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAQAAAP7/////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGFAAAAE1pY3Jvc29mdCBXb3JkILmuvK0ACgAA
AE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AA==

------=_NextPart_000_0020_01C05043.383EE210--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 17 14:05:39 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19601
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 17 Nov 2000 14:05:38 -0500 (EST)
Received: from standards (47.234.32.16:1392) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6A71@standards.nortelnetworks.com>; Fri, 17 Nov 2000 13:46:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 112210 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Nov 2000 13:46:46
          -0500
Received: from myth3.Stanford.EDU by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB6A6F@standards.nortelnetworks.com>; Fri, 17 Nov 2000 13:46:45
          -0500
Received: from localhost (sjtsao@localhost) by myth3.Stanford.EDU (8.9.3/8.9.3)
          with ESMTP id LAA01081 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Fri, 17 Nov 2000 11:03:26 -0800 (PST)
X-Authentication-Warning: myth3.Stanford.EDU: sjtsao owned process doing -bs
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved-By:  Susan Tsao <sjtsao@STANFORD.EDU>
Message-ID:  <Pine.GSO.4.21.0011171056550.29191-100000@myth3.Stanford.EDU>
Date:         Fri, 17 Nov 2000 11:03:26 -0800
Reply-To: Susan Tsao <sjtsao@stanford.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Susan Tsao <sjtsao@stanford.edu>
Subject:      [MOBILE-IP] Mobile IPv6 implementation
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <035901c04fd6$09078fa0$6401a8c0@SOLID>

Hello,

Can someone please direct me to any existing mobile IPv6 implementation
for FreeBSD (with KAME IPV6 implementation) & Linux that conforms to
draft-ietf-mobileip-ipv6-12?


Thanks in advance.
Susan


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 17 16:02:52 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10106
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 17 Nov 2000 16:02:51 -0500 (EST)
Received: from standards (47.234.32.16:1920) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6B4A@standards.nortelnetworks.com>; Fri, 17 Nov 2000 15:44:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 112497 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Nov 2000 15:44:20
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB6B48@standards.nortelnetworks.com>; Fri, 17 Nov 2000 15:44:20
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA13311;
          Fri, 17 Nov 2000 13:00:57 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eAHL0ul27431; Fri, 17 Nov 2000 13:00:56
          -0800
X-Virus-Scanned:  Fri, 17 Nov 2000 13:00:56 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpd46Q6zK; Fri, 17 Nov 2000
          13:00:53 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A159C86.CE8D9875@iprg.nokia.com>
Date:         Fri, 17 Nov 2000 13:00:54 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      [MOBILE-IP] Revised Route Optimization Internet Draft
X-cc:         Dave Johnson <dbj@cs.rice.edu>,
              "Basavaraj Patil (NTC/Dallas)" <Basavaraj.Patil@nokia.com>,
              Phil Roberts <qa3445@email.mot.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello folks,

A new version of the Route Optimization draft has been
made available at the following URL:
        http://www.diameter.org/charliep/txt/optim/optim.txt
This draft is intended to address all comments received
in recent months, especially including those related to
future work on "Mobile IP Based Micro Mobility Management
Protocol in The Third Generation Wireless Network".

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 17 16:28:27 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10921
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 17 Nov 2000 16:28:27 -0500 (EST)
Received: from standards (47.234.32.16:1920) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6BAF@standards.nortelnetworks.com>; Fri, 17 Nov 2000 16:07:31 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 112637 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Nov 2000 16:07:31
          -0500
Received: from mgw-dax2.ext.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB6BAD@standards.nortelnetworks.com>; Fri, 17 Nov 2000 16:07:30
          -0500
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com
          [172.18.242.84]) by mgw-dax2.ext.nokia.com
          (Switch-2.1.0/Switch-2.1.0) with ESMTP id eAHLOQ622076 for
          <mobile-ip@standards.nortelnetworks.com>; Fri, 17 Nov 2000 15:24:36
          -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by
          davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.1.5)
          with ESMTP id <Tac12f2544fef9fc709@davir01nok.americas.nokia.com> for
          <mobile-ip@standards.nortelnetworks.com>; Fri, 17 Nov 2000 15:24:02
          -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id <W9M3N95F>;
          Fri, 17 Nov 2000 15:24:02 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  Basavaraj.Patil@NOKIA.COM
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E5F5@daeis07nok>
Date:         Fri, 17 Nov 2000 15:20:11 -0600
Reply-To: Basavaraj.Patil@nokia.com
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Basavaraj Patil <Basavaraj.Patil@nokia.com>
Subject:      [MOBILE-IP] WG Last Call : draft-ietf-mobileip-gnaie-01.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Folks,

This is a Mobile IP WG last call for the I-D
draft-ietf-mobileip-gnaie-01.txt - Generalized NAI Extension
(GNAIE). This draft will be sent to the IESG requesting a proposed
standard status to be associated with it at the end of the last call
period. Please send your comments to the WG discussion list.

WG Last call issued on : Nov 17, 2000
Expires on : December 4, 2000

Basavaraj Patil
Phil Roberts


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 17 17:19:46 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12645
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 17 Nov 2000 17:19:45 -0500 (EST)
Received: from standards (47.234.32.16:4390) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6C47@standards.nortelnetworks.com>; Fri, 17 Nov 2000 17:01:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 112844 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Nov 2000 17:01:08
          -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB6C45@standards.nortelnetworks.com>; Fri, 17 Nov 2000 17:01:07
          -0500
Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id OAA13462; Fri, 17 Nov 2000 14:17:48
          -0800 (PST)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by
          sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with
          ESMTP id OAA17606; Fri, 17 Nov 2000 14:16:21 -0800 (PST)
Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by
          jurassic.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with SMTP id
          eAHMGHB544121; Fri, 17 Nov 2000 14:16:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: uAEfxqQXxcD9wK2u8E/ZRw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc
Approved-By:  Samita Chakrabarti <Samita.Chakrabarti@ENG.SUN.COM>
Message-ID:  <200011172216.eAHMGHB544121@jurassic.eng.sun.com>
Date:         Fri, 17 Nov 2000 14:16:53 -0800
Reply-To: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>
Subject:      Re: [MOBILE-IP] RFC 2344 Reverse Tunnel Broadcast/Multicast   
              clarification
X-To:         gab@sun.com
X-cc:         kleung@cisco.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi Gabriel,


> both of you interpret the document as it was intended. this interpretation was
not made
> explicit. i'm not sure this is such a terrible oversight, as it does seem that
people draw the
> same conclusion you have drawn. at any rate, the revised version was already
sent
> to the IESG and approved for publication on oct 27. from the IESG queue:
>
> 2000/10/27   draft-ietf-mobileip-rfc2344-bis-02.txt


I think you meant draft-ietf-mobileip-rfc2344-bis-03.txt --right ?


> EDIT/IANA
> G. Montenegro
> Reverse Tunnleing for Mobile IP, revised
>
> this may not mean that it's impossible to add some clarifying text, but it
might not
> be worth it unless it's really essential.
>
> -gabriel
>

I agree with you. Personally I don't have any issues on the implied
interpretation as mentioned above.

Thanks,
-Samita


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 17 17:32:06 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13389
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 17 Nov 2000 17:32:05 -0500 (EST)
Received: from standards (47.234.32.16:4390) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6D0B@standards.nortelnetworks.com>; Fri, 17 Nov 2000 17:13:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 113127 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Nov 2000 17:13:41
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB6D09@standards.nortelnetworks.com>; Fri, 17 Nov 2000 17:13:40
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA21454;
          Fri, 17 Nov 2000 14:29:45 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eAHMTfj32431; Fri, 17 Nov 2000 14:29:41
          -0800
X-Virus-Scanned:  Fri, 17 Nov 2000 14:29:41 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdMVWf7o; Fri, 17 Nov 2000
          14:29:32 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A15B14F.6A340929@iprg.nokia.com>
Date:         Fri, 17 Nov 2000 14:29:35 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      [MOBILE-IP] Internet Draft from MIPv6 fast handover design team
X-To:         Mohamed Khalil <mkhalil@nortelnetworks.com>
X-cc:         Alper Yegin <Alper.Yegin@eng.sun.com>,
              Gopal Dommety <gdommety@cisco.com>,
              George Tsirtsis <g.tsirtsis@flarion.com>,
              Phil Roberts <qa3445@email.mot.com>,
              "Basavaraj Patil (NTC/Dallas)" <Basavaraj.Patil@nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello,

The MIPv6 fast handover design team has issued an initial
Internet Draft detailing the progress in many areas that we
have made to date.  Most of the document describes the
design considerations and scope of the solution we are still
attempting to specify.  While no solutions are proposed,
enough progress has been achieved to warrant the publication
of this initial draft, in order to begin to raise the
appropriate discussion issues as we approach resolution
of the remaining issues.

The initial Internet Draft is available at:
   http://www.diameter.org/charliep/txt/mipv6team/handover.txt

It is also fair to say that some members of the design
team felt that the Internet Draft wasn't truly ready to be
issued.  However, a very rough consensus favored sending
the draft out.

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Nov 18 00:44:05 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22050
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 18 Nov 2000 00:44:04 -0500 (EST)
Received: from standards (47.234.32.16:1859) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6EB2@standards.nortelnetworks.com>; Sat, 18 Nov 2000 0:25:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 113691 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 18 Nov 2000 00:25:19
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB6EB0@standards.nortelnetworks.com>; Sat, 18 Nov 2000 0:25:19
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Fri, 17 Nov 2000 21:34:17 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <W0QN7C0L>; Fri, 17 Nov 2000 21:35:05 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA80130C974@red-msg-06.redmond.corp.microsoft.com>
Date:         Thu, 16 Nov 2000 22:20:52 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Francis Dupont <Francis.Dupont@enst-bretagne.fr>
X-cc:         Charlie Perkins <charliep@iprg.nokia.com>,
              Francis Dupont <Francis.Dupont@inria.fr>,
              Vijay Devarapalli <vijayd@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> PS: I don't believe nothing should be done but there is a
> working solution
> today then we should adopt it *now* and keep the door open.

Mandating that the Home Address option appear before the Fragment header
does not keep the door open for using ESP instead of AH. It slams the door
shut.

Rich


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Nov 18 01:35:16 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26432
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 18 Nov 2000 01:35:15 -0500 (EST)
Received: from standards (47.234.32.16:1859) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6F10@standards.nortelnetworks.com>; Sat, 18 Nov 2000 1:16:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 113822 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 18 Nov 2000 01:16:50
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB6F0E@standards.nortelnetworks.com>; Sat, 18 Nov 2000 1:16:50
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id WAA18360
          for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 17 Nov 2000
          22:33:33 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eAI6XVL19138 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 17 Nov 2000 22:33:31
          -0800
X-Virus-Scanned:  Fri, 17 Nov 2000 22:33:31 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from Icharliep-1.iprg.nokia.com (205.226.22.18,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpddWWi7x; Fri, 17 Nov 2000
          22:33:27 PST
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Charlie Perkins <charliep@IPRG.NOKIA.COM>
Message-ID:  <3A162243.7068510D@iprg.nokia.com>
Date:         Fri, 17 Nov 2000 22:31:31 -0800
Reply-To: Charlie Perkins <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Charlie Perkins <charliep@IPRG.nokia.com>
Organization: Nokia
Subject:      [MOBILE-IP] New draft for Mobile IPv6
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello,

A revised Internet Draft is available for "Mobility Support for IPv6" is
available
at the following URL:
    http://www.diameter.org/charliep/txt/mobilev6/mobilev6.txt

This draft has been submitted to the Internet Draft directories, and is
intended
to address all the issues that have been raised during working group
Last Call.

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Nov 18 10:37:23 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09143
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 18 Nov 2000 10:37:22 -0500 (EST)
Received: from standards (47.234.32.16:3184) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB70CC@standards.nortelnetworks.com>; Sat, 18 Nov 2000 10:18:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 114426 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 18 Nov 2000 10:18:26
          -0500
Received: from hotmail.com (f32.law7.hotmail.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB70CA@standards.nortelnetworks.com>; Sat, 18 Nov 2000
          10:18:25 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat,
          18 Nov 2000 07:35:08 -0800
Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Sat, 18 Nov
          2000 15:35:08 GMT
X-Originating-IP: [63.78.179.5]
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_bf1_39d8_5601"
X-OriginalArrivalTime: 18 Nov 2000 15:35:08.0924 (UTC)
                       FILETIME=[21F71BC0:01C05175]
Approved-By:  Hemant Chaskar <hchaskar@HOTMAIL.COM>
Message-ID:  <F32BWGPfeTW3YkGqQ0M0000073a@hotmail.com>
Date:         Sat, 18 Nov 2000 15:35:08 GMT
Reply-To: Hemant Chaskar <hchaskar@hotmail.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Hemant Chaskar <hchaskar@hotmail.com>
Subject:      [MOBILE-IP] NEW I-D
X-cc:         hemant.chaskar@nokia.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_bf1_39d8_5601
Content-Type: text/plain; format=flowed

Mobile IP WG:

We have submitted the following new I-D to Mobile IP WG-

Title: A Framework for QoS Support in Mobile IPv6
Authors: H. Chaskar and R. Koodli
<draft-chaskar-mobileip-qos-00.txt>

We would appreciate WG's comments on this draft.

A copy of draft is enclosed with this email for quick retrieval.

Thanks.

Hemant Chaskar

(P.S. I apologize if the WG received multiple copies of this
email. But I think the one I sent before did not go through.)




_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.

------=_NextPart_000_bf1_39d8_5601
Content-Type: text/plain; name="MIPv6_QoS.txt"; format=flowed
Content-Disposition: attachment; filename="MIPv6_QoS.txt"
Content-Transfer-Encoding: 8bit

IETF Mobile IP Working Group                              H. Chaskar
INTERNET-DRAFT                                             R. Koodli
Expires: May 2001                              Nokia Research Center
                                                       November 2000

               A Framework for QoS Support in Mobile IPv6
                     draft-chaskar-mobileip-qos-00.txt

Status of This Memo

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

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

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

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

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

Copyright Notice

   Copyright (c) The Internet Society (2000). All rights reserved.


Abstract

This document describes a framework for providing QoS support in
Mobile IPv6. As the Mobile Node changes its point of attachment with
the Internet, the intermediate network domains traversed by its
packets may change. It is required to program appropriate QoS support
for the MN's packets in these network domains, so that the
performance of QoS-sensitive applications running on the MN is
maintained at desired level. To achieve this, we introduce a new IPv6
option called "QoS Object." Depending on the context, the QoS Object
is included as a Destination Option or a Hop-by-Hop Option in IPv6
packets carrying Binding Update and Binding Acknowledgment messages.
When included as a Hop-by-Hop Option, QoS Object triggers certain QoS
procedures at the intermediate network domains. In this document, we
describe these QoS procedures for the cases of best-effort, MPLS,
DiffServ and IntServ domains, which practically cover all the cases
of QoS enabled network domains that would be available in
near future.


Chaskar, Koodli                                             [Page i]

INTERNET-DRAFT        QoS Support in Mobile IPv6       November,2000







                               Contents



Status of This Memo                                                i

Abstract                                                           i

1. Introduction                                                   1

2. Terminology                                                    1

3. QoS Object: A New Option for Mobile IPv6                       2

4. Inclusion of QoS Object Option Along With Binding Messages     3

    4.1  Transactions between the MN and the HA  . . . . . . . .   3
    4.2  Transactions between the MN and the CN  . . . . . . . .   4

5. Processing of QoS Object at Intermediate Network Domains       5

    5.1. Processing at (the edge of) MPLS domain . . . . . . . .   5
    5.2. Processing at (the edge of) DiffServ domain . . . . . .   6
    5.3. Processing at (the edge of) IntServ domain  . . . . . .   7

6. Concluding Remarks                                             8

7. References                                                     9

8. Addresses                                                     10

















Chaskar, Koodli                                            [Page ii]

INTERNET-DRAFT        QoS Support in Mobile IPv6       November,2000

1. Introduction

   The provisions in Mobile IPv6 [1] discussed so far, do not have
   any mechanism to inform the routers or network domains in the path
   between the Home Agent (HA) and the Mobile Node (MN), and between
   the Correspondent Node (CN) and the MN, about the quality of
   service (QoS) requirement of packet streams belonging to the MN.
   Note that these intermediate routers or network domains traversed
   by the MN's packets may change as the MN changes its point of
   attachment. Thus, for example, the packets belonging to MN’s video
   teleconference may get the same forwarding treatment as those
   belonging to its FTP session at the intermediate network domains,
   in the absence of such QoS information. Further, it is not
   possible for the routers or network domains in the end to end path
   to exercise admission control and enforce admission policy, in the
   absence of QoS and traffic volume information about MN's packet
   streams. For example, some intermediate bottleneck network domain
   may not wish to admit high bandwidth video-on-demand packet stream
   of the MN. Motivated by this problem and the fact that IP QoS and
   traffic engineering mechanisms, such as Multiprotocol Label
   Switching (MPLS) [2], Differentiated Services (DiffServ) [3] and
   Integrated Services (IntServ) [4], will be available in near
   future, we describe a framework to bring QoS negotiation
   capabilities to Mobile IPv6.

   This framework is based on the use of new IPv6 option called "QoS
   Object." QoS Object is included, depending on the context, either
   as a Destination Option or as a Hop-by-Hop Option along with the
   packets carrying Binding Update and Binding Acknowledgment
   options. The basic idea is to include QoS Object as a Hop-by-Hop
   option along with the binding message that travels in the same
   direction (HA to MN, CN to MN or MN to CN) as that of MN's
   QoS-sensitive packet stream. As this packet traverses different
   network domains in the end to end path, the QoS Object is examined
   at these network domains to program QoS support for the MN's data
   packets. In general, only the edge routers of these network
   domains examine the QoS Object, while the routers internal to the
   domains either ignore it or they do not see it in cases such as
   label based forwarding of MPLS. Hence, it does not put additional
   processing burden on the internal (core) routers.

   Section 3 describes the composition of QoS Object option. The
   semantics of inclusion of QoS Object option in packets carrying
   binding messages is described in Section 4. Section 5 describes
   the processing that the QoS Object invokes at the edges of MPLS,
   DiffServ and IntServ domains.

2. Terminology

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119[1].

Chaskar, Koodli                                             [Page 1]

INTERNET-DRAFT        QoS Support in Mobile IPv6       November,2000

3. QoS Object: A New Option for Mobile IPv6

   The composition of QoS Object option is shown in Figure 1. This
   option is included in IPv6 packets carrying Binding update and
   Binding Acknowledgment, either as a Destination Option or a
   Hop-by-Hop Option, as described in Section 4. We require as many
   QoS Objects as the number of unidirectional QoS-sensitive packet
   streams between the MN and the CN, while binding messages are used
   on a per-host basis.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1                                  |0|0|1| Opt Type| Opt Data Len  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2  |QoS Requirement(16-bit integer)|        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3  |     Average Data Rate (32-bit IEEE floating point number)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4  |Burstiness:Token Bucket Size(32-bit IEEE floating point number)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5  |     Peak Data Rate  (32-bit IEEE floating point number)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6  |        Minimum Policed Unit  (32-bit integer)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7  |        Maximum Packet Size  (32-bit integer)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8  |                         Flags (Future use)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9  |                                                               |
   +         Values of Packet Classification Parameters            +
10 |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 1: Composition of QoS Object option

   - The "QoS Requirement" field describes the QoS requirement of the
     MN's packet stream. An example is the QoS specification in terms
     of traffic classes, such as conversational, streaming,
     interactive and background, as in the UMTS QoS classes
     specification [5]. Each of these classes will be assigned a
     unique integer value.

  - The next five fields constitute the "Traffic Volume" information.
     These fields indicate the amount of traffic that the MN's packet
     stream will generate. The parameters that are used to describe
     the Traffic Volume are taken from RSVP SENDER_TSPEC object [6].

   - Finally, "Packet Classification" information fields describe the
     values of packet header fields that can be used to identify the
     packets of the MN's packet stream at the (edges of) intermediate
     network domains. Typically, the parameters such as, source and

Chaskar, Koodli                                             [Page 2]

INTERNET-DRAFT        QoS Support in Mobile IPv6       November,2000

     destination IP addresses, TCP and UDP port numbers, and IPv6
     flow label, are used for packet classification purposes. Note
     that the values of source and destination IP addresses to be
     used for packet classification can be always inferred from the
     header of the packet carrying QoS Object itself (see Section 4
     also). However, values of parameters such as TCP/UDP port
     numbers and IPv6 flow labels may be required to be explicitly
     carried in the QoS Object to indicate which packet stream of the
     MN the given QoS Object corresponds to. This is because, binding
     messages are sent on a per-host basis while QoS Object is for
     each packet stream. The Flags field is kept for future use. The
     intent is to use it to specify if certain packet classification
     parameters in the above list are to be explicitly ignored.

   Now, we describe semantics of the inclusion of QoS Object option
   in packets carrying binding messages to the HA and the CN.

4. Inclusion of QoS Object Option Along with Binding Messages

   The basic idea here is to include the QoS Object as a Hop-by-Hop
   Option along with the binding message that travels between the MN
   and the HA or between the MN and the CN in the same direction as
   the MN's QoS-sensitive packet stream. The QoS Object can then
   inform the intermediate network domains about the QoS requirement
   of the relevant packet stream. This information will be used by
   these intermediate network domains to program appropriate QoS
   support for the data packets of the packet stream that will arrive
   subsequent to this binding message.

4.1 Transactions between the MN and the HA

   With respect to the HA, the only relevant direction of MN's data
   traffic is from the HA to the MN and there is no traffic in the
   opposite direction. Hence, QoS support needs to be negotiated only
   in a direction from the HA to the MN. This is achieved by
   including the QoS Object option along with the binding messages
   sent to the HA as follows:

   1. MN includes the QoS Object as a Destination Option along with
   the Binding Update that is sent to the HA. This Binding Update is
   sent with Acknowledgment bit set to one, indicating that the HA
   is required to acknowledge this Binding Update.

   2. HA verifies the QoS Object in Destination Option and includes
   it, with possible modification, as a Hop-by-Hop Option along with
   the packet carrying Binding Acknowledgment.

   3. The relevant routers (see Section 5) at the intermediate
   network domains traversed by Binding Acknowledgment examine the
   QoS Object option to determine the QoS requirement of the MN's
   packet streams that will flow from the HA to the MN, subsequent
   to this Binding Acknowledgment. The Traffic Volume fields in the

Chaskar, Koodli                                             [Page 3]

INTERNET-DRAFT        QoS Support in Mobile IPv6       November,2000

   QoS Object will indicate the amount of traffic that the MN's
   packet streams will bring to the network domain, and the Packet
   Classification information fields in the QoS Object will indicate
   the values of fields in the packet headers that can be used to
   identify the packets of MN's packet streams. This information is
   used by the routers to:

   i.  Take admission control decision, and

   ii. Program forwarding treatment that needs to be offered to the
   packets of MN's packet streams at the network domain under
   consideration.

   This is further described in Section 5.

4.2 Transactions between the MN and the CN

   Whenever, MN changes its point of attachment to the Internet, it
   may also send Binding Update to CN for the sake of route
   optimization of downlink traffic. For the sake of QoS negotiation
   with the intermediate network domains, MN creates QoS Objects and
   includes them with the Binding Update, as described below. With
   respect to the CN, the direction of MN's data traffic can be from
   the CN to the MN (downlink) as well as from the MN to the CN
   (uplink). As stated earlier, one QoS Object corresponds to one
   unidirectional QoS-sensitive packet stream. The transactions with
   the CN are as follows:

   1. The uplink QoS Object is included as a Hop-by-Hop
   Option and the downlink QoS Object is included as a Destination
   Option along with the Binding Update that is sent to the CN. This
   Binding Update is sent with Acknowledgment bit set to one,
   indicating that the CN is required to acknowledge this Binding
   Update.

   2. The relevant routers (see Section 5) at the intermediate
   network domains, traversed by Binding Update examine the uplink
   QoS Object to determine the QoS requirement of the packets that
   will flow from MN to CN, subsequent to this Binding Update. As
   mentioned earlier, the routers make use of the information in the
   uplink QoS Object to perform admission control and program packet
   forwarding treatment.

   3. Upon receiving the Binding Update, the CN verifies the
   downlink QoS Object in the Destination Option and includes it,
   with possible modifications, as a Hop-by-Hop Option along with
   the packet carrying Binding Acknowledgment.

   4. The relevant routers (see Section 5) at the intermediate
   network domains, traversed by Binding Acknowledgment examine the
   downlink QoS Object to determine the QoS requirement of the
   packets that will flow from CN to MN, subsequent to this Binding

Chaskar, Koodli                                             [Page 4]

INTERNET-DRAFT        QoS Support in Mobile IPv6       November,2000

   Acknowledgment. As mentioned earlier, the routers make use of the
   information in the downlink QoS Object to perform admission
   control and program packet forwarding treatment.

   In certain cases, by virtue of admission control, some network
   domain in the end to end path may not wish to accommodate all the
   traffic indicated by the Traffic Volume field in the QoS Object
   with the requested QoS as indicated by the QoS Requirement field.
   The relevant router at that network domain can then modify the
   fields in the QoS Object so that they are in conformance with the
   QoS support that this domain is capable of.

5. Processing of QoS Object at Intermediate Network Domains

   When QoS Object in included as a Hop-by-Hop Option in IPv6 packet,
   the intermediate routers examine this option. Typically, there are
   multiple and possibly heterogeneous (as regards QoS mechanism
   employed) network domains between the MN and the HA, and between
   the MN and the CN. Here, a network domain is defined as a
   collection of network nodes (routers) that implements a particular
   QoS mechanism independently and under the same control plane.
   There are Edge Routers (ER) at the edge of these domains and
   Internal Routers (IR) within the domains. Each of these domains
   may be best-effort domain or may employ QoS mechanisms such as
   MPLS, DiffServ or IntServ. The case of best-effort domain is
   trivial as the routers (edge and internal) belonging to such
   domain simply ignore the QoS Object. This leaves us with the
   interesting case of QoS-enabled domains.

5.1 Processing at (the edge of) MPLS domain

   In an MPLS domain [2], when a set of data units (IP packets)
   traverses a common path through the network domain, a Label
   Switched Path (LSP) can be established using MPLS signaling
   protocols. This set is then called as belonging to the same
   Forwarding Equivalence Class (FEC). At the ingress Label Switch
   Router (LSR), each packet in this set is assigned a label that
   corresponds to the relevant FEC and it is transmitted downstream.
   At each LSR along the LSP, the label is used to forward the
   packet to the next hop. Label-based forwarding paradigm enhances
   scalability of packet forwarding engines as they are relieved of
   routing table lookup as well as due to reduction in the size of
   forwarding database by virtue of label merging capability of
   MPLS. Further, MPLS is a very useful tool for traffic
   engineering [7].

   When IPv6 packet containing QoS Object as a Hop-by-Hop Option,
   arrives at the ER (also called as ingress LSR) of MPLS domain,
   the ER determines, based on the destination address of the packet
   and the QoS Object in the Hop-by-Hop Option, the FEC to which the
   packets of the corresponding stream belong. FEC in turn
   translates to the LSP that the subsequent packets of this stream

Chaskar, Koodli                                             [Page 5]

INTERNET-DRAFT        QoS Support in Mobile IPv6       November,2000

   should traverse through that domain. Such LSPs for different
   traffic classes are typically pre-established by the service
   provider between different ingress-egress router pairs, during
   traffic engineering phase. The ER then creates "FEC Mapping
   Context" that will map the subsequent packets of the MN’s packet
   stream under consideration to this FEC or LSP. The Packet
   Classification information fields in the QoS Object are used to
   identify the subsequent packets of this packet stream at the ER.
   Due to this FEC Mapping Context, appropriate label is attached to
   the subsequent packets of the MN’s packet stream under
   consideration at the ER. These packets then traverse thus
   determined LSP, while transiting through the network domain under
   consideration. Note that such Mapping Context is required for any
   traffic (not only Mobile IPv6 traffic) that is to be forwarded
   using label-based paradigm. Hence, the edge LSRs at MPLS domain
   already have this functionality.

   The ER then forwards the packet containing the QoS Object to the
   destination ER of the same LSP, over the same LSP or over some
   other LSP. Forwarding this packet on LSP as well, achieves the
   desirable result that the IRs in the domain do not have to
   examine the QoS Object option. Precisely, due to label-based
   forwarding paradigm they do not even see the IP header.

5.2 Processing at (the edge of) DiffServ domain

   The DiffServ QoS architecture [3] is based on a model where
   traffic entering a network domain is classified and possibly
   conditioned at the boundaries of the network domain, and assigned
   to different behavior aggregates. Each behavior aggregate is
   identified by a unique DiffServ Code Point (DSCP). DSCP is
   included in the IP header of the packet at the ER of the domain.
   DiffServ proposes differentiation in the queuing and forwarding
   treatment received by packets at the routers in the network
   domain, on the basis of DSCPs included in their headers at the ER
   of the domain. IETF has standardized two groups of behavior
   aggregates, namely expedited forwarding or EF (one instance or
   class) and assured forwarding or AF (four instances or classes
   each containing three drop-precedence levels).

   When IPv6 packet containing QoS Object as a Hop-by-Hop Option,
   arrives at the ER of DiffServ domain, the ER determines, using
   QoS Object in the Hop-by-Hop Option, the forwarding treatment
   that the subsequent packets of this stream should get within the
   corresponding network domain. In particular, the QoS Requirement
   field in the QoS Object indicates the behavior aggregate that the
   packets of MN’s packet stream should be assigned to. Further, the
   Traffic Volume fields enable the ER to exercise admission
   control, and possibly, initialize the parameters for traffic
   conditioner for the MN’s packet streams. The ER also programs
   "Classifier Context" that would mark the subsequent data packets
   of the MN’s packet streams with appropriate DSCPs relevant for

Chaskar, Koodli                                             [Page 6]

INTERNET-DRAFT        QoS Support in Mobile IPv6       November,2000

   that domain. Packet Classification information fields in the QoS
   Object are used to identify the subsequent packets of this stream.
   Finally, note that the packet classification and traffic
   conditioning functionality is required at the ER of DiffServ
   domain for any traffic (not only Mobile IPv6 traffic).

   If DiffServ is used in conjunction with MPLS [8], subsequent
   forwarding of the packet containing QoS Object through that
   domain is as described in Section 5.1, i. e., over LSP. Else, the
   packet containing QoS Object is forwarded through the network
   domain in a hop-by-hop fashion. IRs in the network domain simply
   ignore the QoS Object. Note that, in the latter case, since IRs
   are employing hop-by-hop forwarding of packets, their
   architecture is already tailored to perform hop-by-hop processing
   of packets. Hence, accessing (and later ignoring) QoS Object does
   not put additional burden on these routers.

5.3 Processing at (the edge of) IntServ domain

   IntServ QoS mechanism defines service classes, such as guaranteed
   service and controlled-load service, that if supported by the
   routers in the network domain can provide the data flow with
   certain QoS commitments. The level of QoS provided by these
   classes is programmable on a per-flow basis. The QoS requests can
   be passed to the routers in the network domain using a
   reservation protocol called RSVP. The requests dictate the level
   of resources, such as bandwidth and buffer space, that must be
   reserved along with the transmission scheduling behavior that
   must be installed in the routers to provide the desired QoS
   commitment for the data flow. IntServ QoS mechanism has not
   gained much popularity due to its poor scalability. Nonetheless,
   we cover this case here for the sake of  completeness.

   When IPv6 packet containing QoS Object arrives at the ER of
   IntServ domain, the ER initiates resource reservation process as
   described in [4]. In particular, it first determines, based on
   the destination address of this IPv6 packet, the egress ER for
   this domain. Based on basic IntServ paradigm (RSVP messaging), in
   the present context, there are a number of alternatives to
   perform resource reservation in the network domain. Here we
   describe one illustrative example.

   The ingress ER sends PATH message to thus determined egress ER.
   It uses Traffic Volume and Packet Classification information
   fields in the QoS Object to construct Sender_TSpec and
   Sender_Template for the PATH message. It includes (a version of)
   QoS Requirement field in the Destination Option of IPv6 packet
   carrying the PATH message. Note that the destination address for
   packet carrying PATH message is the egress ER. This would inform
   the egress ER about the required QoS support so that it can
   compare it with the performance calculated based on the available
   resources and other parameters recorded by the IRs in, say, AdSpec

Chaskar, Koodli                                             [Page 7]

INTERNET-DRAFT        QoS Support in Mobile IPv6       November,2000

   of PATH message. If sufficient resources are available to support
   the required QoS, the egress ER sends RESV towards the ingress ER.
   Upon, the receipt of RESV at the ingress ER, ingress ER forwards
   the IPv6 packet containing QoS Object along the same path. The IRs
   on this path simply ignore the QoS Object Hop-by-Hop Option. By
   virtue of the resource reservation just established, subsequent
   packets of the MN's will get the desired QoS as they are
   forwarded along the path over which resources are just reserved.

6. Concluding Remarks

   We described a solution for end to end QoS negotiation for
   applications running on Mobile IPv6. The solution is based on
   the inclusion of QoS Object in packets carrying binding messages
   between the MN and the HA and between the MN and the CN. We
   described the processing of QoS Object when included as a
   hop-by-hop option for the cases of best-effort, MPLS, DiffServ and
   IntServ domains, and showed that the solution integrates elegantly
   with these QoS mechanisms.

   For the deployment of the proposed QoS solution for Mobile IPv6,
   two important steps are required. The first is standardization of
   the fields of QoS Object option. The other is implementation of a
   routine in the edge routers of network domains that would
   interpret the QoS Object and communicate with the QoS control
   plane in that network domain. Note that the support for
   hop-by-hop options is already a requirement in IPv6
   specification [9].

   The QoS solution described in this document works for the general
   case where the intermediate network domains traversed by the MN’s
   packets change as a result of change in point of attachment of the
   MN with the Internet. However, certain local optimizations to this
   solution are possible. For example, it is possible to store QoS
   Object at the router where the MN attaches to the Internet. When
   the MN changes its point of attachment to another router, the QoS
   Object can be relocated from the old router to the new router as
   a part of context transfer procedure. When the MN sends Binding
   Update from the new point of attachment, instead of including the
   detailed QoS Object, it can include the QoS Object with a
   particular bit pattern in the QoS Requirement field indicating
   that the router has to fill in the details of QoS Object in this
   packet. Such an extension to the basic solution will reduce the
   wireless bandwidth consumption. Further, certain optimizations are
   possible if regionalized mobility management schemes, such as
   regional registration, are employed. These are the topics of
   future study.






Chaskar, Koodli                                             [Page 8]

INTERNET-DRAFT        QoS Support in Mobile IPv6       November,2000

7. References

   [1] D. Johnson and C. Perkins. Mobility Support in IPv6. Internet
       Draft, Internet Engineering Task Force.
       draft-ietf-mobileip-ipv6-12.txt. April 2000.

   [2] E. Rosen, A. Viswanathan, and R. Callon. Multiprotocol Label
       Switching Architecture. Internet Draft, Internet Engineering
       Task Force. draft-ietf-mpls-arch-06.txt. July 2000.

   [3] S. Blake et. al. An Architecture for Differentiated Services.
       Request for Comments (Informational) 2475. December 1998.

   [4] R. Braden and L. Zhang. Resource ReSerVation Protocol (RSVP):
       Version 1 Functional Specification. Request for Comments
       (Standards track) 2205.  September 1997.

   [5] 3GPP Technical Specification 23.107, Version 3.2.0: QoS
       Concept and Architecture, March 2000.

   [6] J. Wroclawski. The Use of RSVP with IETF Integrated Services.
       Request for Comments 2210 (Standards Track). September 1997.

   [7] D. Awduche et. al. Requirements for Traffic Engineering Over
       MPLS. Request for Comments (Informational) 2702.
       September 1997.

   [8] F. Faucheur et. al. MPLS Support of Differentiated Services.
       Internet Draft, Internet Engineering Task Force.
       draft-ietf-mpls-diff-ext-07.txt. August 2000.

   [9] S. Deering and R. Hinden. Internet Protocol, Version 6
       (IPv6). Request for Comments 2460. December 1998.




















Chaskar, Koodli                                             [Page 9]

INTERNET-DRAFT        QoS Support in Mobile IPv6       November,2000

8. Addresses

  The working group can be contacted via the current chairs:

     Basavaraj Patil                     Phil Roberts
     Nokia Corporation                   Motorola
     6000 Connection Drive               1501 West Shure Drive
     M/S M8-540
     Irving, Texas 75039                 Arlington Heights, IL 60004
     USA                                 USA
     Phone:  +1 972-894-6709             Phone:  +1 847-632-3148
     Fax :  +1 972-894-5349
     EMail:  Basavaraj.Patil@nokia.com   EMail:  QA3445@email.mot.com


  Questions about this memo can be directed to the authors:

   Hemant Chaskar
   Communication Systems Laboratory
   Nokia Research Center
   5 Wayside Road
   Burlington, MA 01803, USA
   Phone: +1 781-993-3785
   EMail: hemant.chaskar@nokia.com

   Rajeev Koodli
   Communication Systems Laboratory
   Nokia Research Center
   313 Fairchild Drive
   Mountain View, CA 94043, USA
   Phone: +1 650-625-2359
   EMail: rajeev.koodli@nokia.com





















Chaskar, Koodli                                            [Page 10]


------=_NextPart_000_bf1_39d8_5601--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Nov 18 11:47:11 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09878
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 18 Nov 2000 11:47:10 -0500 (EST)
Received: from standards (47.234.32.16:2082) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7133@standards.nortelnetworks.com>; Sat, 18 Nov 2000 11:28:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 114569 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 18 Nov 2000 11:28:37
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB7131@standards.nortelnetworks.com>; Sat, 18 Nov 2000 11:28:36
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAIGj9b48883; Sat, 18 Nov 2000 17:45:09 +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 RAA03730; Sat, 18 Nov 2000 17:45:05 +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.9.3/8.9.3) with
          ESMTP id RAA04916; Sat, 18 Nov 2000 17:47:30 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011181647.RAA04916@givry.rennes.enst-bretagne.fr>
Date:         Sat, 18 Nov 2000 17:47:30 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Richard Draves <richdr@microsoft.com>
X-cc:         Charlie Perkins <charliep@iprg.nokia.com>,
              Francis Dupont <Francis.Dupont@inria.fr>,
              Vijay Devarapalli <vijayd@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Thu, 16 Nov 2000 22:20:52 PST. 
              <7695E2F6903F7A41961F8CF888D87EA80130C974@red-msg-06.redmond.corp.microsoft.com>

 In your previous mail you wrote:

   > PS: I don't believe nothing should be done but there is a
   > working solution
   > today then we should adopt it *now* and keep the door open.

   Mandating that the Home Address option appear before the Fragment header
   does not keep the door open for using ESP instead of AH. It slams the door
   shut.

=> the door was already shut by RFC 1825 and 2401, ie. far before the
first mobile IPv6 draft. I don't know if you propose to use ESP in
transport mode but in this case "In general, a packet's source address
MUST match the SA selector value" applies then this doesn't work.
For ESP in tunnel mode the argument is a bit different because RFC 2401
is not very clear about this but many IPsec implementations check to outer
source address then for interoperability reasons the Home Address MUST
appear before ESP in tunnel mode.

If you read my draft (draft-dupont-destoptupd-00.txt) you can see I tried
to clarify things, not to add new constraints (no real new "MUSTs").
For instance, most things are for the sending side: at the receiving
side most of old "SHOULDs" remain but if RFC 2460 mandates to be able
to decode headers in near any order the advanced API (and any reasonable
API) doesn't give the freedom to do silly things.

Thanks

Francis.Dupont@enst-bretagne.fr

PS: I am updating an other draft (draft-ietf-ngtrans-hometun-00.txt)
with many considerations about real world problems with ESP in tunnel
mode then if you'd like to reuse mobile IPv6 signaling in a VPN world
you can join us but this will be a long term work!


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Nov 19 00:51:27 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21071
	for <mobileip-archive@LISTS.IETF.ORG>; Sun, 19 Nov 2000 00:51:26 -0500 (EST)
Received: from standards (47.234.32.16:2776) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7363@standards.nortelnetworks.com>; 19 Nov 2000 0:32:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 115344 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 19 Nov 2000 00:32:16
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB7361@standards.nortelnetworks.com>; 19 Nov 2000 0:32:16 -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Sat, 18 Nov 2000 21:47:46 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <W0QN972T>; Sat, 18 Nov 2000 21:48:33 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA8014691A9@red-msg-06.redmond.corp.microsoft.com>
Date:         Sat, 18 Nov 2000 21:48:24 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Francis Dupont <Francis.Dupont@enst-bretagne.fr>
X-cc:         Charlie Perkins <charliep@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>    Mandating that the Home Address option appear before the
> Fragment header
>    does not keep the door open for using ESP instead of AH.
> It slams the door
>    shut.
>
> => the door was already shut by RFC 1825 and 2401, ie. far before the
> first mobile IPv6 draft. I don't know if you propose to use ESP in
> transport mode but in this case "In general, a packet's source address
> MUST match the SA selector value" applies then this doesn't work.

I do have transport mode in mind, although I wouldn't want to preclude
tunnel mode.

You are referring to RFC 2401 5.2.1. That section does NOT preclude the Home
Address option from appearing after an ESP header. An implementation can
work as follows:
1. find the SA, based on destination address, SPI, and IPsec protocol
2. use the SA to authenticate and decrypt.
3. locate the Home Address & other selector values.
4. compare the selector values against those in the SA.
Steps 3 & 4 can either be done immediately after step 2 (which would require
looking ahead in the packet) or lazy-evaluated ie postponed until after some
processing of a following destination options header.

I have an existence proof that an implementation like this is possible. I
understand that your implementation doesn't work this way and that you don't
care to change it. If that's the basis for your argument, you should say so
- appealing to RFC 2401 won't work.

Rich


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Nov 19 01:54:04 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27611
	for <mobileip-archive@LISTS.IETF.ORG>; Sun, 19 Nov 2000 01:54:03 -0500 (EST)
Received: from standards (47.234.32.16:1394) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB73C3@standards.nortelnetworks.com>; 19 Nov 2000 1:35:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 115475 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 19 Nov 2000 01:35:31
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB73C1@standards.nortelnetworks.com>; 19 Nov 2000 1:35:29 -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Sat, 18 Nov 2000 22:51:26 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <W0QN904P>; Sat, 18 Nov 2000 22:52:14 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA8014691AA@red-msg-06.redmond.corp.microsoft.com>
Date:         Sat, 18 Nov 2000 22:52:10 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] New draft for Mobile IPv6
X-To:         Charlie Perkins <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> A revised Internet Draft is available for "Mobility Support
> for IPv6" is
> available
> at the following URL:
>     http://www.diameter.org/charliep/txt/mobilev6/mobilev6.txt
>
> This draft has been submitted to the Internet Draft
> directories, and is
> intended
> to address all the issues that have been raised during working group
> Last Call.

I'm still looking for clarification of the issues I raised in the below
email. I've only seen one response (thanks Francis) and it left me with the
impression that there isn't consensus on these questions, which are rather
important for interoperability.

Thanks,
Rich

> -----Original Message-----
> From: Richard Draves
> Sent: Monday, November 13, 2000 9:06 PM
> To: Mobile IP (E-mail); IPsec (E-mail)
> Subject: mobile IPv6 & IPsec policies
>
>
> I have some questions about the interactions between mobile
> IPv6 and IPsec policy selection (SPD lookup) and IKE (SA
> negotiation) in draft-ietf-mobileip-ipv6-12, especially
> sections 4.4 and 10.2. If this is all obvious to others then
> perhaps the draft could be clarified. It's not obvious to me
> and I don't know enough about IPsec & IKE to be certain of
> the answers.
>
> I believe the draft says/implies: the security policies on
> the mobile node do not usually change when the mobile node
> moves, and policy lookups use home addresses, not care-of addresses.
>
> A. What policy selectors should be used when
> sending/receiving a Binding Update? Section 10.2 says:
>
>     -  As part of outbound packet processing in IP, the packet is
>        compared against the IPsec Security Policy Database (SPD) to
>        determine what processing is required for the packet [13].
>
>     -  As a special case for Mobile IP, if a Binding Update or
>        Binding Acknowledgement is being included in the packet, IPsec
>        authentication, integrity protection, and replay
> protection MUST
>        be applied to the packet [13, 11, 12], as defined in
> Section 4.4.
>        If the SPD check above has already indicated that
> authentication
>        and replay protection are required, this processing is
> sufficient
>        for the Mobile IP requirement that all packets
> containing Binding
>        Updates or Binding Acknowledgements be authenticated
> and covered
>        by replay protection.  Otherwise, an implementation can force
>        the required IPsec processing on this individual packet by, for
>        example, creating a temporary SPD entry for the
> handling of this
>        packet.
>
> Suppose you are piggy-backing a Binding Update on a TCP or
> UDP packet, but the selectors find a policy of "no IPsec
> needed" in the SPD. Then Mobile IPv6 is saying, you should
> negotiate and use an SA anyway, because the Binding Update
> needs to be protected. The suggestion is to create a
> temporary SPD entry. What should this temporary SPD entry
> contain? What transforms should be proposed in the ensuing
> IKE negotation? What if there is a policy, but it doesn't
> provide the required protections - if you try to negotiate an
> SA with IKE for transforms that aren't in the policy, isn't
> the correspondent likely to reject the proposals when they
> don't match its policy?
>
> Suppose this is a "naked" Binding Update, not piggy-backed on
> a TCP or UDP packet. What selectors should be used in the
> policy lookup? Should there be a policy lookup at all, or
> should you instead try to find & use any suitable existing SA
> between the two machines? It seems like a naked Binding
> Update should reuse if possible an existing SA between the
> two machines.
>
>
> B. Suppose the mobile node's home is in the same organization
> as the correspondent node (ie normally no IPsec needed for
> communication between home location & correspondent), but the
> mobile node is away from home. In fact there is a Security
> Gateway between the mobile node and the correspondent node,
> and the mobile node needs to use one SA to communicate with
> the SG (say ESP tunnel-mode) and a second SA (say
> transport-mode AH) to send binding-updates through to the
> correspondent node. A policy lookup on the mobile node based
> solely on the home address will not work because the result
> will be "no IPsec needed". Even if you force the use of IPsec
> to protect the Binding Updates (as discussed above), you
> won't know to negotiate a tunnel-mode SA and communicate via the SG.
>
> One possibility (that I like) is that Mobile IPv6 effectively
> mandates that policies that need communication via a security
> gateway must be implemented in the routing table via a tunnel
> interface, instead of in the SPD. However, mandating this
> style of implementation for security gateway policies would
> be a departure from the base IPsec standard as I understand
> it. For one thing, because routing table lookups are usually
> based just on destination address and don't take into account
> the other IPsec selectors, this would limit the kinds of
> policies that you could use.
>
> An alternative would be to say the mobile node does TWO
> lookups in the SPD, one using its home address and another
> using its care-of address, and merges the resulting policies
> that it gets from those two lookups. Actually it gets more
> complicated, because there might be an HA->CoA mapping for
> the destination as well as the source address. The tunnel
> interface approach to dealing with security gateways seems simpler.
>
> Thanks,
> Rich
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Nov 19 13:37:48 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11757
	for <mobileip-archive@LISTS.IETF.ORG>; Sun, 19 Nov 2000 13:37:48 -0500 (EST)
Received: from standards (47.234.32.16:1512) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB769F@standards.nortelnetworks.com>; 19 Nov 2000 13:19:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 116520 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 19 Nov 2000 13:19:03
          -0500
Received: from audrey.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBB769D@standards.nortelnetworks.com>; 19 Nov 2000 13:19:02 -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by audrey.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP
          id eAJIZT638017; Sun, 19 Nov 2000 19:35:29 +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 TAA11532; Sun, 19 Nov 2000 19:34:12 +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.9.3/8.9.3) with
          ESMTP id TAA09165; Sun, 19 Nov 2000 19:36:44 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011191836.TAA09165@givry.rennes.enst-bretagne.fr>
Date:         Sun, 19 Nov 2000 19:36:44 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Richard Draves <richdr@microsoft.com>
X-cc:         Charlie Perkins <charliep@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Sat, 18 Nov 2000 21:48:24 PST. 
              <7695E2F6903F7A41961F8CF888D87EA8014691A9@red-msg-06.redmond.corp.microsoft.com>

 In your previous mail you wrote:

   >    Mandating that the Home Address option appear before the
   > Fragment header
   >    does not keep the door open for using ESP instead of AH.
   > It slams the door
   >    shut.
   >
   > => the door was already shut by RFC 1825 and 2401, ie. far before the
   > first mobile IPv6 draft. I don't know if you propose to use ESP in
   > transport mode but in this case "In general, a packet's source address
   > MUST match the SA selector value" applies then this doesn't work.

   I do have transport mode in mind, although I wouldn't want to preclude
   tunnel mode.

   You are referring to RFC 2401 5.2.1.

=> yes, the section which mandates the check of the source address as
the second step of inbound IPsec header processing:
 - this step must be done before the processing of the next IPsec header
   (then you proposal won't work directly with more than one IPsec header)
 - in this step the code is not supposed to look at the next header
   (but you can say this is implementation dependent)
 - many implementations do the check in the step 1 (lookup).
   I know this is not a RFC 2401 compliant behavior (the check is in step 2
   because in tunnel mode the source address to check is the inner one)
   but this likely interoperability problem IMHO justifies a MUST.

   That section does NOT preclude the Home
   Address option from appearing after an ESP header. An implementation can
   work as follows:

=> do you propose to change all IPsec implementations?

   1. find the SA, based on destination address, SPI, and IPsec protocol
   2. use the SA to authenticate and decrypt.
   3. locate the Home Address & other selector values.
   4. compare the selector values against those in the SA.
   Steps 3 & 4 can either be done immediately after step 2 (which would require
   looking ahead in the packet) or lazy-evaluated ie postponed until after some
   processing of a following destination options header.

=> lazy-evaluation is not an option if you'd like to support the multiple
IPsec header case.

   I have an existence proof that an implementation like this is possible.

=> I never say it is not possible but it is not RFC 2401 compliant
(not a real problem if you keep the behavior without new security issues)
and this is *not* the way existent implementations (with one exception) work.

   I understand that your implementation doesn't work this way

=> KAME implementation what I use doesn't check the source address
(I don't matter because I have disable the tunnel mode)...

   and that you don't care to change it.

=> ask Itojun (:-). I am afraid that near all implementors won't care to
change their implementation when there is a simpler and cleaner solution.

   If that's the basis for your argument, you should say so
   - appealing to RFC 2401 won't work.

=> please bring the discussion to the IPsec mailing list. I'd like to
get the rationale for this section of RFC 2401 (and some others).


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Nov 19 16:24:17 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12865
	for <mobileip-archive@LISTS.IETF.ORG>; Sun, 19 Nov 2000 16:24:16 -0500 (EST)
Received: from standards (47.234.32.16:2603) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB771E@standards.nortelnetworks.com>; 19 Nov 2000 16:05:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 116696 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 19 Nov 2000 16:05:41
          -0500
Received: from mail.cs.umn.edu by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB771C@standards.nortelnetworks.com>; 19 Nov 2000 16:05:40 -0500
Received: from tera.cs.umn.edu (rakshe@tera.cs.umn.edu [128.101.35.163]) by
          mail.cs.umn.edu (8.9.3/8.9.3) with ESMTP id PAA22572 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sun, 19 Nov 2000 15:22:27
          -0600 (CST)
Received: from localhost (rakshe@localhost) by tera.cs.umn.edu (8.9.1/8.9.0)
          with ESMTP id PAA10610 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Sun, 19 Nov 2000 15:22:26 -0600 (CST)
X-Authentication-Warning: tera.cs.umn.edu: rakshe owned process doing -bs
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved-By:  Rohit Rakshe <rakshe@CS.UMN.EDU>
Message-ID:  <Pine.GSO.4.30.0011191458260.9889-100000@tera.cs.umn.edu>
Date:         Sun, 19 Nov 2000 15:22:26 -0600
Reply-To: Rohit Rakshe <rakshe@cs.umn.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Rohit Rakshe <rakshe@cs.umn.edu>
Subject:      [MOBILE-IP] Cellular IP questions
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi,

I am a graduate student at University of Minnesota. I read cellular IP
draft and  have some questions  about it. (I  am assuming this  is the
correct mailing list  to discuss this. If not,  can someone please let
me know ?)

1. Cell-IP  updates   binding  caches  of   routers  on  the   way  to
gateway. Does this not mean that  the domain topology HAS to be a tree
structure.  Because if  it was  not a  tree, then  there could  be two
distinct paths from the mobile node  to the gateway. And then we could
not update binding caches of routers on the way.

Now, if such  restriction is indeed placed, it  limits the topology of
the domain severely (and we are losing robustness of IP).


2. If a mobile  node (A) is sending packets to  some other mobile node
(B) located very close in  the same cellular domain, the packets could
be routed straight  to (B) because mobile nodes  always use their home
IP addresses. But cell-IP says that all packets have to be routed thru
the gateway. This might not be the best thing to do.

Why can't  we just  send those  packets directly to  (B) and  then the
router  which intercepts the  packets on  the way  to gateway  send an
empty data  packet addressed to the  gateway on (A)'s  behalf (for the
purpose of updating  binding caches of the routers all  the way to the
gateway.).


I would  appreciate your  replies. I  am studying this  as part  of my
project.

Thanks,
Rohit


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 20 02:35:38 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02501
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 20 Nov 2000 02:35:38 -0500 (EST)
Received: from standards (47.234.32.16:4163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB79F3@standards.nortelnetworks.com>; Mon, 20 Nov 2000 2:15:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 117673 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 02:15:54
          -0500
Received: from mailbreak.com (216.207.225.170:4988) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB79F1@standards.nortelnetworks.com>; Mon, 20 Nov 2000
          2:15:53 -0500
Received: from SOLID [166.84.159.26] by mailbreak.com [216.207.225.174] with
          SMTP (MDaemon.v3.5.0.R) for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Mon, 20 Nov 2000 02:25:33 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_02DF_01C0529A.B1540A50"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-MDRemoteIP: 166.84.159.26
X-Return-Path: eunsoo@ctr.columbia.edu
X-MDaemon-Deliver-To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Approved-By:  Eunsoo Shim <eunsoo@CTR.COLUMBIA.EDU>
Message-ID:  <02e201c052c4$9a7684a0$6401a8c0@SOLID>
Date:         Mon, 20 Nov 2000 02:36:31 -0500
Reply-To: Eunsoo Shim <eunsoo@ctr.columbia.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Eunsoo Shim <eunsoo@ctr.columbia.edu>
Subject:      [MOBILE-IP] new I-D
X-cc:         Rich Gitlin <rich@ee.columbia.edu>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

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

Hi,

We have submitted a new I-D to the Mobile IP WG recently.

Title: Fast Handoff Using Neighbor Information
Authors: Eunsoo Shim, Richard D. Gitlin
File: draft-shim-mobileip-neighbor-00.txt

It is available at
http://www.ctr.columbia.edu/~eunsoo/paper/draft-shim-mobileip-neighbor-00=
.txt

We'd appreciate your comments on the drafts.
Thanks.

Eunsoo
PS) The following is the abstract of the draft.

Abstract=20
   =20
   We propose a new fast handoff mechanism in wireless IP using=20
   neighboring Foreign Agent information. Our proposal is based on the=20
   policy of utilizing, or perhaps even wasting, wired bandwidth between =

   Foreign Agents, while minimizing rf (radio frequency) bandwidth=20
   exchanges, in order that handoff latency is minimized. We minimize=20
   the handoff latency by initiating data forwarding to the possible new =

   foreign agent candidates (i.e., the neighbor foreign agents)=20
   immediately when the mobile node is about to start the link layer=20
   handoff procedure. This proposal builds upon the Mobile IP handoff=20
   procedure by adding a couple of additional message types. The handoff =

   mechanism is a unified procedure for inter- and intra-domain handoffs =

   and provides flexible choices to the network while maintaining=20
   transparency to the mobile node. The neighbor learning process is a=20
   distributed and dynamic mechanism.=20


------=_NextPart_000_02DF_01C0529A.B1540A50
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.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#c0c0c0>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>Hi,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>We have submitted a new I-D to the Mobile IP WG=20
recently.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Title: Fast Handoff Using Neighbor =
Information</FONT></DIV>
<DIV><FONT size=3D2>Authors: Eunsoo Shim, Richard D. Gitlin</FONT></DIV>
<DIV><FONT size=3D2>File: =
draft-shim-mobileip-neighbor-00.txt</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>It is available at</FONT></DIV>
<DIV><FONT size=3D2><A=20
href=3D"http://www.ctr.columbia.edu/~eunsoo/paper/draft-shim-mobileip-nei=
ghbor-00.txt">http://www.ctr.columbia.edu/~eunsoo/paper/draft-shim-mobile=
ip-neighbor-00.txt</A></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>We'd appreciate your comments on the =
drafts.</FONT></DIV>
<DIV><FONT size=3D2>Thanks.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Eunsoo</FONT></DIV>
<DIV><FONT size=3D2>PS) The following is the abstract of the =
draft.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Abstract <BR>&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp; We =
propose a=20
new fast handoff mechanism in wireless IP using <BR>&nbsp;&nbsp; =
neighboring=20
Foreign Agent information. Our proposal is based on the <BR>&nbsp;&nbsp; =
policy=20
of utilizing, or perhaps even wasting, wired bandwidth between =
<BR>&nbsp;&nbsp;=20
Foreign Agents, while minimizing rf (radio frequency) bandwidth =
<BR>&nbsp;&nbsp;=20
exchanges, in order that handoff latency is minimized. We minimize=20
<BR>&nbsp;&nbsp; the handoff latency by initiating data forwarding to =
the=20
possible new <BR>&nbsp;&nbsp; foreign agent candidates (i.e., the =
neighbor=20
foreign agents) <BR>&nbsp;&nbsp; immediately when the mobile node is =
about to=20
start the link layer <BR>&nbsp;&nbsp; handoff procedure. This proposal =
builds=20
upon the Mobile IP handoff <BR>&nbsp;&nbsp; procedure by adding a couple =
of=20
additional message types. The handoff <BR>&nbsp;&nbsp; mechanism is a =
unified=20
procedure for inter- and intra-domain handoffs <BR>&nbsp;&nbsp; and =
provides=20
flexible choices to the network while maintaining <BR>&nbsp;&nbsp; =
transparency=20
to the mobile node. The neighbor learning process is a <BR>&nbsp;&nbsp;=20
distributed and dynamic mechanism. </FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_02DF_01C0529A.B1540A50--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 20 11:36:10 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19141
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 20 Nov 2000 11:36:06 -0500 (EST)
Received: from standards (47.234.32.16:2196) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7E3B@standards.nortelnetworks.com>; Mon, 20 Nov 2000 11:16:48 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 119148 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 11:16:47
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB7E39@standards.nortelnetworks.com>; Mon, 20 Nov 2000 11:16:46
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Mon, 20 Nov 2000 08:30:47 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <X289RBCM>; Mon, 20 Nov 2000 08:31:36 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA801469224@red-msg-06.redmond.corp.microsoft.com>
Date:         Mon, 20 Nov 2000 08:31:28 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] New draft for Mobile IPv6
X-To:         Jean-Michel COMBES <jeanmichel.combes@rd.francetelecom.fr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I think everyone wants a Destination Options header behind the AH/ESP
header, to contain a Binding Update option. We've been discussing the
placement of the Home Address option, which I think belongs in the same
place.

> -----Original Message-----
> From: Jean-Michel COMBES
> [mailto:jeanmichel.combes@rd.francetelecom.fr]
> Sent: Monday, November 20, 2000 7:29 AM
> To: Richard Draves
> Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] New draft for Mobile IPv6
>
>
>
> Hi,
>
> just one question : why do you want DO-H@ behind AH/ESP Hdr ?
>
> Regards.
>
>
> Richard Draves a ecrit :
>
> > > A revised Internet Draft is available for "Mobility Support
> > > for IPv6" is
> > > available
> > > at the following URL:
> > >     http://www.diameter.org/charliep/txt/mobilev6/mobilev6.txt
> > >
> > > This draft has been submitted to the Internet Draft
> > > directories, and is
> > > intended
> > > to address all the issues that have been raised during
> working group
> > > Last Call.
> >
> > I'm still looking for clarification of the issues I raised
> in the below
> > email. I've only seen one response (thanks Francis) and it
> left me with the
> > impression that there isn't consensus on these questions,
> which are rather
> > important for interoperability.
> >
> > Thanks,
> > Rich
>
> --
>
> France Telecom R&D - DTL/SSR
> Jean-Michel COMBES, Internet/Intranet Security
> E-Mail : jeanmichel.combes@rd.francetelecom.fr
> Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
> PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214
>
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 20 11:36:11 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19167
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 20 Nov 2000 11:36:11 -0500 (EST)
Received: from standards (47.234.32.16:2196) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7E3F@standards.nortelnetworks.com>; Mon, 20 Nov 2000 11:16:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 119152 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 11:16:51
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB7E3D@standards.nortelnetworks.com>; Mon, 20 Nov 2000 11:16:50
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Mon, 20 Nov 2000 08:30:47 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <X289RBCN>; Mon, 20 Nov 2000 08:31:36 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA801469227@red-msg-06.redmond.corp.microsoft.com>
Date:         Mon, 20 Nov 2000 08:31:28 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Francis Dupont <Francis.Dupont@enst-bretagne.fr>
X-cc:         Charlie Perkins <charliep@iprg.nokia.com>,
              Markku Savela <Markku.Savela@research.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> => do you propose to change all IPsec implementations?

Adding mobile node support will require some change to all implementations.
It's a question of how much changes. For your implementation, you're saying
that allowing the Home Address option to appear after the IPsec headers will
require substantial change. For my implementation (and Markku's
implementation), it does not require much change.

> => lazy-evaluation is not an option if you'd like to support
> the multiple
> IPsec header case.

Not true. Again, I have an existence proof.

> => I never say it is not possible but it is not RFC 2401 compliant
> (not a real problem if you keep the behavior without new
> security issues)
> and this is *not* the way existent implementations (with one
> exception) work.

I think it is compliant. And more than one implementation works this way.

>
>    I understand that your implementation doesn't work this way
>
> => KAME implementation what I use doesn't check the source address
> (I don't matter because I have disable the tunnel mode)...
>
>    and that you don't care to change it.
>
> => ask Itojun (:-). I am afraid that near all implementors
> won't care to
> change their implementation when there is a simpler and
> cleaner solution.

I think there's some debate what is "simpler and cleaner".

>
>    If that's the basis for your argument, you should say so
>    - appealing to RFC 2401 won't work.
>
> => please bring the discussion to the IPsec mailing list. I'd like to
> get the rationale for this section of RFC 2401 (and some others).
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 20 11:47:18 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21478
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 20 Nov 2000 11:47:17 -0500 (EST)
Received: from standards (47.234.32.16:2196) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7EAF@standards.nortelnetworks.com>; Mon, 20 Nov 2000 11:28:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 119307 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 11:28:23
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB7EAD@standards.nortelnetworks.com>; Mon, 20 Nov 2000 11:28:22
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Mon, 20 Nov 2000 08:41:54 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <X289R1BA>; Mon, 20 Nov 2000 08:42:43 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA80146922E@red-msg-06.redmond.corp.microsoft.com>
Date:         Mon, 20 Nov 2000 08:42:37 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] RFC 2401 section 5.2.1
X-To:         Markku Savela <Markku.Savela@research.nokia.com>
X-cc:         ipsec@lists.tislabs.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I'm cc'ing the mobile-ip list - I hope this works better than the last time
I tried to send a message to both ipsec & mobile-ip.

Our implementation uses the "lazy-evaluate" strategy, very much like you
describe and for the same reasons.

The security policy questions that you raise at the end of our message have
not yet been resolved satisfactorily, that I know of.

Thanks,
Rich

> -----Original Message-----
> From: Markku Savela [mailto:Markku.Savela@research.nokia.com]
> Sent: Monday, November 20, 2000 2:23 AM
> To: ipsec@lists.tislabs.com
> Subject: RE: RFC 2401 section 5.2.1
>
>
>
> > From: EXT Richard Draves
>
> > In this case, we want to check the Home Address
> > against the SA. But the Home Address hasn't been
> > seen yet - it's in a Home Address option in the
> > next header.
>
> ..or even later headers. Nothing says it must follow the
> IPSEC headers.
>
> > I think an implementation can either look ahead to
> > find the Home Address (much like you look ahead to
> > find selectors in the transport header), *or*
> > an implementation can "lazy evaluate" this check,
> > postponing it until after the destination options
> > header is processed.
>
> > Some questions:
> > a) Do you agree that Mobile IPv6's requirement that
> > AH be used and not ESP
> > is too restrictive?
>
> Too restrictive. Decision should be on the policy writer, not
> hardcode in to
> the implementations.
>
> > b) Is the receiver processing that I'm proposing legitimate?
>
> > c) If Mobile IPv6 support is added to your IPsec
> > implementation, would this Home Address processing
> > be unduly difficult for your implementation to
> > support?
>
> Not after realizing that the "lazy evaluate" is the only one
> that really
> works easily (at least for me). I had to go to "lazy evaluation" on my
> implementation,
>
> 1) because after processing the IPSEC headers, there might be other
> extension headers before the transport layer. => Cannot check
> policy because
> skipping unknown extension headers is impossible [one cannot know the
> structure of unknown extension headers. In my architecture,
> there is no
> fixed set of supported headers. When new extension header is
> defined, the
> existing stack can be made to support it just by writing a
> loadable handler
> for it.]
>
> 2) what now happens is that my "IPSEC AH/ESP" handler gets
> called for each
> AH and ESP, and also just before passing the packet to the
> upper layer. The
> SA's of AH and ESP are remembered, and the policy check
> occurs at the call
> that happens before upper layer. Thus, the next header in
> turn at that point
> is always the upper layer header and easily looked at. The
> src and dst are
> the current "effective" ones.
>
> 3) I presume that whatever logic is decided on Home Address
> option handling,
> can be now fitted into this fairly easily.
>
> On receive side, the processing is fairly deterministic. I'm
> more uncertain
> about the outbound direction. How does the IPSEC required by
> Binding Update
> activate (enable destination options in selectors -- I don't
> like that)?
> What to do if IPSEC requirement of Binding Update and some
> other security
> policy are in conflict (require different protection).
> Prevent "piggybacked"
> Binding updates, send them always separate?
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 21 00:20:08 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02594
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Nov 2000 00:20:07 -0500 (EST)
Received: from standards (47.234.32.16:4988) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8418@standards.nortelnetworks.com>; Tue, 21 Nov 2000 0:01:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 121207 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 00:00:11
          -0500
Received: from ws130.nomadiclab.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB83FB@standards.nortelnetworks.com>; Tue, 21 Nov 2000 0:00:10
          -0500
Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by
          ws130.nomadiclab.com (Postfix) with ESMTP id 7E20172504 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 21 Nov 2000 07:17:02
          +0200 (EET)
Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com
          (Postfix) with ESMTP id 0A3C6BA08 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 21 Nov 2000 07:17:02
          +0200 (EET)
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fi
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Pekka Nikander <Pekka.Nikander@NOMADICLAB.COM>
Message-ID:  <3A1A0598.828606A8@nomadiclab.com>
Date:         Tue, 21 Nov 2000 07:18:16 +0200
Reply-To: Pekka Nikander <Pekka.Nikander@nomadiclab.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pekka Nikander <Pekka.Nikander@nomadiclab.com>
Subject:      [MOBILE-IP] A new (but compatible) approach to do Mobile IP in v6
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

We have been considering IPv6 mobility in the context of ad hoc
networks and future wireless devices for some time now.  Along
this work, combined with the ongoing discussion about a mobile
host having several interfaces and therefore several COAs, we've
got an idea that seems like a new one, and produced a related I-D,
http://www.ietf.org/internet-drafts/draft-nikander-mobileip-homelessv6-00.txt

The basic idea is to replace the Binding Cache with what we
call a Host Cache.  While a Binding Cache entry contains a
HA->COA mapping, a Host Cache entry is basically a set of
addresses that are known to belong to a single host.  Sockets
are no more associated with single addresses, but with Host
Cache entries.  This allows source and destination addresses
to be selected on individual packet bases, etc.

Yes, we know that some applications will break, including
FTP and probably a number of UDP applications.  However, since
most of these applications would need to be modified in order
to support IPv6 anyway, maybe that problem would not be that big.

A summary of the background thinking leading to this idea
can be found in
http://www.tml.hut.fi/~pnr/publications/nikander_huc2k.pdf,
and a slightly updated version of the I-D is available at
http://www.tml.hut.fi/~pnr/publications/draft-nikander-mobileip-homelessv6-00.txt

We are currently working on a FreeBSD based prototype implementation,
and should have it out by the San Diego meeting.

--Pekka Nikander
  Ericsson Research NomadicLab


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 21 07:37:56 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16309
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Nov 2000 07:37:56 -0500 (EST)
Received: from standards (47.234.32.16:4583) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB86CF@standards.nortelnetworks.com>; Tue, 21 Nov 2000 7:18:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 122125 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 07:18:43
          -0500
Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB86CD@standards.nortelnetworks.com>; Tue, 21 Nov 2000
          7:18:43 -0500
Received: from p-grive.issy.cnet.fr ([139.100.0.85]) by p-voyageur.issy.cnet.fr
          with SMTP (Microsoft Exchange Internet Mail Service Version
          5.5.2650.21) id WZ8ALH33; Tue, 21 Nov 2000 13:31:40 +0100
Received: from rd.francetelecom.fr (p-dico.issy.cnet.fr [139.100.18.135]) by
          p-grive.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id VC12YYHA; Tue, 21 Nov 2000 13:31:40
          +0100
X-Mailer: Mozilla 4.7 [fr] (WinNT; U)
X-Accept-Language: fr
MIME-Version: 1.0
References: <3984.974769943@coconut.itojun.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Approved-By:  Jean-Michel COMBES <jeanmichel.combes@RD.FRANCETELECOM.FR>
Message-ID:  <3A1A6B67.6F5176C6@rd.francetelecom.fr>
Date:         Tue, 21 Nov 2000 13:32:39 +0100
Reply-To: Jean-Michel COMBES <jeanmichel.combes@rd.francetelecom.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Jean-Michel COMBES <jeanmichel.combes@rd.francetelecom.fr>
Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D
Subject:      Re: [MOBILE-IP] RFC 2401 section 5.2.1
X-To:         itojun@iijlab.net
X-cc:         Henry Spencer <henry@spsystems.net>,
              Richard Draves <richdr@microsoft.com>,
              ipsec@lists.tislabs.com, Francis Dupont 
              <Francis.Dupont@enst-bretagne.fr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

itojun@iijlab.net a écrit :

> >On Sun, 19 Nov 2000, Richard Draves wrote:
> >> a) Do you agree that Mobile IPv6's requirement that AH be used and not ESP
> >> is too restrictive?
> >Strongly agree.  We'd like to see AH die entirely, and hence are opposed
> >to having any other standard demand its continued survival.
>
>         (again this holy war on AH)
>         I don't.  if you use transport mode IPsec heavily (unlike today's
>         VPN-only situation) how can you protect your header portion?

JMC :
You will use a Alternate Care-of Address Sub-Option, containing the CoA ( == IPv6
Hdr Src Addr), behind the DO-BU, but, IMO, this is a heavy solution : we have the
same thing twice ... In my point of view, DO-HA before AH/ESP plus AH mecanism is
the simplest solution.

>
>         since the introduction of IPsec there are so many protocols that rely
>         upon the use of IPsec to protect it.  I wonder what is their underlying
>         security model.
>
> itojun

JMC :
One thing I don't understand is what are the advantages to have the DO-HA behind
AH/ESP ? If it's a question of privacy (ie. hiding the MN location), I think that
doesn't resolve the problem unless to hide the Routing Header, which contains MN's
Home Address, coming from the Home Agent for the BAck.
On the other hand, having the DO-HA before the AH/ESP Hdr, will simplify
considerably filtering policy in FW (ie. filtering based on MN Home Address).

Regards.

--

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : jeanmichel.combes@rd.francetelecom.fr
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 21 10:29:39 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20908
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Nov 2000 10:29:38 -0500 (EST)
Received: from standards (47.234.32.16:1266) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB879C@standards.nortelnetworks.com>; Tue, 21 Nov 2000 10:10:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 122395 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 10:10:47
          -0500
Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB879A@standards.nortelnetworks.com>; Tue, 21 Nov 2000 10:10:46
          -0500
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA19928 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 21 Nov 2000 08:27:39
          -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116])
          by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id IAA20011 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 21 Nov 2000 08:25:04
          -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2651.58) id
          <WSGVNK0F>; Tue, 21 Nov 2000 09:27:38 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain
Approved-By:  Roberts Philip-qa3445 <Philip_Roberts-qa3445@EMAIL.MOT.COM>
Message-ID:  <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D2CF@il27exm03.cig.mot.com>
Date:         Tue, 21 Nov 2000 09:27:36 -0600
Reply-To: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Subject:      [MOBILE-IP] WG Last Call: Mobile IP
              v6:draft-ietf-mobileip-ipv6-13.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Folks,

This is a Mobile IP WG last call for the I-D
draft-ietf-mobileip-ipv6-13.txt - Generalized NAI Extension
(GNAIE). This draft will be sent to the IESG requesting a proposed
standard status to be associated with it at the end of the last call
period. Please send your comments to the WG discussion list.

Although the draft has been submitted to the Internet Directory it has not
appeared on the website yet.  In the meantime it can be viewed at:
http://www.diameter.org/charliep/txt/mobilev6/mobilev6.txt

WG Last call issued on : Nov 21, 2000
Expires on : December 8, 2000

Basavaraj Patil
Phil Roberts


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 21 10:37:10 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22527
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Nov 2000 10:37:10 -0500 (EST)
Received: from standards (47.234.32.16:1266) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB87C8@standards.nortelnetworks.com>; Tue, 21 Nov 2000 10:15:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 122456 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 10:15:20
          -0500
Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB87C6@standards.nortelnetworks.com>; Tue, 21 Nov 2000 10:15:20
          -0500
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA24381 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 21 Nov 2000 08:32:12
          -0700 (MST)]
Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101])
          by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA08279 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 21 Nov 2000 08:32:12
          -0700 (MST)]
Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2651.58) id
          <WMSCVP0R>; Tue, 21 Nov 2000 09:32:00 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain
Approved-By:  Roberts Philip-qa3445 <Philip_Roberts-qa3445@EMAIL.MOT.COM>
Message-ID:  <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D2D0@il27exm03.cig.mot.com>
Date:         Tue, 21 Nov 2000 09:32:07 -0600
Reply-To: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Subject:      [MOBILE-IP] WG Last Call: Route Optimization:
              draft-ietf-mobileip-optim-10.tx
              t
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Folks,

This is a Mobile IP WG last call for the I-D
draft-ietf-mobileip-optim-10.txt - Route Optimization in Mobile IP. This draft will be sent to the IESG requesting a proposed
standard status to be associated with it at the end of the last call
period. Please send your comments to the WG discussion list.

Although the draft has been submitted to the Internet Directory it has not appeared on the website yet.  In the meantime it can be viewed at:
http://www.diameter.org/charliep/txt/optim/optim.txt

WG Last call issued on : Nov 21, 2000
Expires on : December 8, 2000

Basavaraj Patil
Phil Roberts


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 21 10:37:12 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22537
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Nov 2000 10:37:11 -0500 (EST)
Received: from standards (47.234.32.16:1266) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB87D8@standards.nortelnetworks.com>; Tue, 21 Nov 2000 10:17:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 122478 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 10:17:07
          -0500
Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB87D6@standards.nortelnetworks.com>; Tue, 21 Nov 2000 10:17:02
          -0500
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by
          motgate.mot.com (motgate 2.1) with ESMTP id IAA29209 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 21 Nov 2000 08:33:54
          -0700 (MST)]
Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102])
          by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id IAA07276 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 21 Nov 2000 08:33:54
          -0700 (MST)]
Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id
          <WMS1DYAA>; Tue, 21 Nov 2000 09:33:53 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain
Approved-By:  Roberts Philip-qa3445 <Philip_Roberts-qa3445@EMAIL.MOT.COM>
Message-ID:  <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D2D1@il27exm03.cig.mot.com>
Date:         Tue, 21 Nov 2000 09:33:46 -0600
Reply-To: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile IP             v6:draft-ietf
              -mobileip-ipv6-13.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Botched.  Name is not Generalized NAI Extension, but Mobility Support in IPv6.  Sorry about that folks.


> ----------
> From:         Roberts Philip-qa3445
> Reply To:     Roberts Philip-qa3445
> Sent:         Tuesday, November 21, 2000 11:27 PM
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      [MOBILE-IP] WG Last Call: Mobile IP             v6:draft-ietf-mobileip-ipv6-13.txt
>
> Folks,
>
> This is a Mobile IP WG last call for the I-D
> draft-ietf-mobileip-ipv6-13.txt - Generalized NAI Extension
> (GNAIE). This draft will be sent to the IESG requesting a proposed
> standard status to be associated with it at the end of the last call
> period. Please send your comments to the WG discussion list.
>
> Although the draft has been submitted to the Internet Directory it has not
> appeared on the website yet.  In the meantime it can be viewed at:
> http://www.diameter.org/charliep/txt/mobilev6/mobilev6.txt
>
> WG Last call issued on : Nov 21, 2000
> Expires on : December 8, 2000
>
> Basavaraj Patil
> Phil Roberts
>
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 21 10:51:36 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26111
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Nov 2000 10:51:35 -0500 (EST)
Received: from standards (47.234.32.16:1266) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8864@standards.nortelnetworks.com>; Tue, 21 Nov 2000 10:32:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 122674 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 10:32:44
          -0500
Received: from news.comp.lancs.ac.uk by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB8862@standards.nortelnetworks.com>; Tue, 21 Nov 2000 10:32:43
          -0500
Received: from TRINITY (ega096000012.lancs.ac.uk [148.88.155.94]) by
          news.comp.lancs.ac.uk (8.10.2/8.10.2) with SMTP id eALFoBh24780 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 21 Nov 2000 15:50:11
          GMT
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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Approved-By:  Daniel Prince <d.prince@COMP.LANCS.AC.UK>
Message-ID:  <INEHIONEIBNCPNEHNEOCMEJKCAAA.d.prince@comp.lancs.ac.uk>
Date:         Tue, 21 Nov 2000 15:50:54 -0000
Reply-To: Daniel Prince <d.prince@comp.lancs.ac.uk>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Daniel Prince <d.prince@comp.lancs.ac.uk>
Subject:      [MOBILE-IP] Dynamic Home agent Address Discovery
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,
I'm looking at some of the Dynamic Home Agent Address Discovery stuff and
have found that I cannot find any references to the type value for the ICMP
message. This may have already been covered previously on the mailing list,
but I have only just joined the list so might be unaware of the solution(s).

Could someone help me out?

Cheers,
Daniel Prince


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 21 11:07:12 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29731
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Nov 2000 11:07:11 -0500 (EST)
Received: from standards (47.234.32.16:1266) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB88ED@standards.nortelnetworks.com>; Tue, 21 Nov 2000 10:48:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 122862 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 10:48:09
          -0500
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB88EB@standards.nortelnetworks.com>; Tue, 21 Nov 2000
          10:48:08 -0500
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP
          id eALG50t15046; Tue, 21 Nov 2000 17:05:01 +0100 (MET)
Received: from era.ericsson.se by era-t.ericsson.se
          (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id RAA07741; Tue, 21 Nov 2000 17:04:56
          +0100
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
References: <7695E2F6903F7A41961F8CF888D87EA8014691AA@red-msg-06.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Mattias Pettersson <mattias.pettersson@ERA.ERICSSON.SE>
Message-ID:  <3A1A9D19.D1DC2FC9@era.ericsson.se>
Date:         Tue, 21 Nov 2000 17:04:41 +0100
Reply-To: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Radio Systems AB
Subject:      Re: [MOBILE-IP] New draft for Mobile IPv6
X-To:         Richard Draves <richdr@microsoft.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Richard Draves wrote:

> I'm still looking for clarification of the issues I raised in the below
> email. I've only seen one response (thanks Francis) and it left me with the
> impression that there isn't consensus on these questions, which are rather
> important for interoperability.
>
I would go for Home Address option between Routing Header and Fragment
Header. IMHO this is the logical place to put it with respect to the
order headers are processed and with no respect to existing
implementations of whatsoever protocol.

If we have a chance to put it where it should belong, let's do it before
specs get more fixed.

/Mattias


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 21 13:16:16 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27520
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Nov 2000 13:16:13 -0500 (EST)
Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8A40@standards.nortelnetworks.com>; Tue, 21 Nov 2000 12:57:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 123314 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 12:57:11
          -0500
Received: from mailbreak.com (216.207.225.170:4151) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB8A3E@standards.nortelnetworks.com>; Tue, 21 Nov 2000
          12:57:11 -0500
Received: from edell [210.101.1.125] by mailbreak.com [216.207.225.174] with
          SMTP (MDaemon.v3.5.0.R) for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Tue, 21 Nov 2000 13:07:03 -0500
References:  <4B6BC00CD15FD2119E5F0008C7A419A5089EB32D@eaubrnt018.epa.ericsson.se>
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0234_01C053BD.E821AFA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-MDRemoteIP: 210.101.1.125
X-Return-Path: eunsoo@ctr.columbia.edu
X-MDaemon-Deliver-To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Approved-By:  Eunsoo Shim <eunsoo@CTR.COLUMBIA.EDU>
Message-ID:  <023701c053e7$d2c524a0$bb0265d2@edell>
Date:         Tue, 21 Nov 2000 13:21:07 -0500
Reply-To: Eunsoo Shim <eunsoo@ctr.columbia.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Eunsoo Shim <eunsoo@ctr.columbia.edu>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
              hes
X-cc:         Rich Gitlin <rich@ee.columbia.edu>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

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

RE: [MOBILE-IP] Differences between the two MIPv4 handoff =
approachesPlease excuse my joining this discussion so late.
I'd like to know what could be an example of existing wireless network =
capable of discovery of the new FA's IP address by the old FA from the =
L2 handoff as suggested in the Proactive Handoff proposal.
Or I'd appreciate any idea of how it could be done in existing wireless =
networks or future wireless networks.
If this information is available somewhere, would you please give me the =
pointer to it?
Thanks.

Eunsoo
  ----- Original Message -----=20
  From: Hesham Soliman (EPA)=20
  To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM=20
  Sent: Thursday, October 05, 2000 4:21 PM
  Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff =
approac hes


  Pete,=20

    Registering after=20
    the L2 handoff removes this dependency.  Also it eliminates the=20
    configuration headaches that are implicit in the Fast Handoffs=20
    scheme: how does the current FA get the advertisement from the=20
    next FA, how does it propagate the registration over multiple=20
    routing hops, and how does the new FA associate the registration=20
    with the soon-to-be-established link-layer connection?=20

    I'm surprised you're bringing this up again. Please refer to our=20
    previous discussion in the archive and the draft.=20

    While we're repeating questions :=20
    How does a proactive FA get the "next" FA's IP address ?=20




------=_NextPart_000_0234_01C053BD.E821AFA0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [MOBILE-IP] Differences between the two MIPv4 =
handoff approaches</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Please excuse my joining this =
discussion so=20
late.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I'd like to know what could be an =
example of=20
existing wireless network&nbsp;capable of discovery of the new FA's IP =
address=20
by the old FA from the L2 handoff as suggested in the Proactive Handoff=20
proposal.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Or I'd appreciate any idea of how it =
could be done=20
in existing wireless networks or future wireless networks.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>If this information is available =
somewhere, would=20
you please give me the pointer to it?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Eunsoo</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:Hesham.Soliman@ERICSSON.COM.AU"=20
  title=3DHesham.Soliman@ERICSSON.COM.AU>Hesham Soliman (EPA)</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM"=20
  =
title=3DMOBILE-IP@STANDARDS.NORTELNETWORKS.COM>MOBILE-IP@STANDARDS.NORTEL=
NETWORKS.COM</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, October 05, =
2000 4:21=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [MOBILE-IP] =
Differences=20
  between the two MIPv4 handoff approac hes</DIV>
  <DIV><BR></DIV>
  <P><FONT color=3D#0000ff face=3DArial size=3D2>Pete, </FONT></P>
  <UL>
    <P><FONT face=3DArial size=3D2>Registering after</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>the L2 handoff removes this dependency.&nbsp; Also it =
eliminates=20
    the</FONT> <BR><FONT face=3DArial size=3D2>configuration headaches =
that are=20
    implicit in the Fast Handoffs</FONT> <BR><FONT face=3DArial =
size=3D2>scheme: how=20
    does the current FA get the advertisement from the</FONT> <BR><FONT=20
    face=3DArial size=3D2>next FA, how does it propagate the =
registration over=20
    multiple</FONT> <BR><FONT face=3DArial size=3D2>routing hops, and =
how does the=20
    new FA associate the registration</FONT> <BR><FONT face=3DArial =
size=3D2>with=20
    the soon-to-be-established link-layer connection?</FONT> </P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2>I'm surprised you're =
bringing this=20
    up again. Please refer to our </FONT><BR><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2>previous discussion in the archive and the draft. =
</FONT></P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2>While we're repeating =
questions=20
    :</FONT> <BR><FONT color=3D#0000ff face=3DArial size=3D2>How does a =
proactive FA=20
    get the "next" FA's IP address ?</FONT> =
</P><BR></UL></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0234_01C053BD.E821AFA0--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 21 13:24:16 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29467
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Nov 2000 13:24:16 -0500 (EST)
Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8A5C@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:00:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 123350 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 13:00:23
          -0500
Received: from mailbreak.com (216.207.225.170:4166) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB8A5A@standards.nortelnetworks.com>; Tue, 21 Nov 2000
          13:00:23 -0500
Received: from edell [210.101.1.125] by mailbreak.com [216.207.225.174] with
          SMTP (MDaemon.v3.5.0.R) for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Tue, 21 Nov 2000 13:10:09 -0500
References:  <5F05C89FB2F8D211B6430008C791912703EA81B2@esealnt190>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-MDRemoteIP: 210.101.1.125
X-Return-Path: eunsoo@ctr.columbia.edu
X-MDaemon-Deliver-To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Approved-By:  Eunsoo Shim <eunsoo@CTR.COLUMBIA.EDU>
Message-ID:  <024e01c053e8$41a3b620$bb0265d2@edell>
Date:         Tue, 21 Nov 2000 13:24:13 -0500
Reply-To: Eunsoo Shim <eunsoo@ctr.columbia.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Eunsoo Shim <eunsoo@ctr.columbia.edu>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
              hes
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Pat and Karim,

Would you mind giving me a few examples of those wireless networks described
in the below?
I'd just like to know about it.
Thanks.

Eunsoo

----- Original Message -----
From: "Karim El-Malki (ERA)" <Karim.El-Malki@ERA.ERICSSON.SE>
To: <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Sent: Friday, October 06, 2000 12:02 PM
Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
hes


> >
> > I believe that Pete's common on real time has to do with the
> > current state of
> > some cellular networks. In some of these technologies, the
> > Mobile gets a
> > message, informing it to do a handoff. There is no extra time
> > for the mobile
> > to register. Tom Hiller stated this on the v4 handoff design
> > team conference
> > call, but I believe you weren't on that particular call.
>
> I am aware of this and am not disagreeing.
> My point is that the registration can be done before the Mobile
> gets the L2 message informing it to handoff. Thus we require
> interworking between L2 and L3 on the network-side (which is
> needed anyway) such that L3 registration can occur at the same
> time as L2 signalling and such that the L2 handoff message is
> sent after the L3 registration. As I wrote in my reply to Pete,
> this is what is summed up in point 2) of the list of differences
> sent out.
>
> Regards,
> Karim
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 21 13:42:08 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02709
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Nov 2000 13:42:07 -0500 (EST)
Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8BD0@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:20:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 123862 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 13:20:39
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB8BCE@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:20:38
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Tue, 21 Nov 2000 10:36:41 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <XLGKV6SH>; Tue, 21 Nov 2000 10:37:30 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA80130C99E@red-msg-06.redmond.corp.microsoft.com>
Date:         Tue, 21 Nov 2000 10:37:17 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      [MOBILE-IP] FW: RFC 2401 section 5.2.1
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

fyi - some discussion from the ipsec list. From what I can tell, the
mobile-ip list rewrites message headers so we can't have a discussion
spanning both lists.

-----Original Message-----
From: Henry Spencer [mailto:henry@spsystems.net]
Sent: Monday, November 20, 2000 11:30 AM
To: Richard Draves
Cc: ipsec@lists.tislabs.com; Francis Dupont
Subject: RE: RFC 2401 section 5.2.1


On Sun, 19 Nov 2000, Richard Draves wrote:
> a) Do you agree that Mobile IPv6's requirement that AH be used and not ESP
> is too restrictive?

Strongly agree.  We'd like to see AH die entirely, and hence are opposed
to having any other standard demand its continued survival.

> b) Is the receiver processing that I'm proposing legitimate?

I'd say it is, with the caveat that I haven't worked with IPv6 enough yet
to really have a good feel for its header processing.

> c) If Mobile IPv6 support is added to your IPsec implementation, would
this
> Home Address processing be unduly difficult for your implementation to
> support?

FreeS/WAN is still far enough away from IPv6 support of any flavor that
it's hard to be sure, but it doesn't sound too bad.

                                                          Henry Spencer
                                                       henry@spsystems.net


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 21 17:00:40 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12239
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Nov 2000 17:00:39 -0500 (EST)
Received: from standards (47.234.32.16:1205) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8DD3@standards.nortelnetworks.com>; Tue, 21 Nov 2000 16:42:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 124558 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 16:42:05
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBB8DD1@standards.nortelnetworks.com>;
          Tue, 21 Nov 2000 16:42:04 -0500
Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id OAA04039; Tue, 21 Nov 2000 14:58:57
          -0700 (MST)
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,v1.7) with ESMTP id
          NAA29265; Tue, 21 Nov 2000 13:58:56 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id NAA14281; Tue, 21 Nov 2000 13:58:55
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Patrice Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.974843762.25250.pcalhoun@nasnfs>
Date:         Tue, 21 Nov 2000 13:56:02 -0800
Reply-To: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
              hes
X-To:         Eunsoo Shim <eunsoo@ctr.columbia.edu>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" <024e01c053e8$41a3b620$bb0265d2@edell>

> Pat and Karim,
>
> Would you mind giving me a few examples of those wireless networks described
> in the below?

CDMA and 802.11 are two examples where a mobile is instructed that it being
handed off. The mobile does not have any "spare" time to send packets to
assist in the handoff process.

PatC

> I'd just like to know about it.
> Thanks.
>
> Eunsoo
>
> ----- Original Message -----
> From: "Karim El-Malki (ERA)" <Karim.El-Malki@ERA.ERICSSON.SE>
> To: <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
> Sent: Friday, October 06, 2000 12:02 PM
> Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
> hes
>
>
> > >
> > > I believe that Pete's common on real time has to do with the
> > > current state of
> > > some cellular networks. In some of these technologies, the
> > > Mobile gets a
> > > message, informing it to do a handoff. There is no extra time
> > > for the mobile
> > > to register. Tom Hiller stated this on the v4 handoff design
> > > team conference
> > > call, but I believe you weren't on that particular call.
> >
> > I am aware of this and am not disagreeing.
> > My point is that the registration can be done before the Mobile
> > gets the L2 message informing it to handoff. Thus we require
> > interworking between L2 and L3 on the network-side (which is
> > needed anyway) such that L3 registration can occur at the same
> > time as L2 signalling and such that the L2 handoff message is
> > sent after the L3 registration. As I wrote in my reply to Pete,
> > this is what is summed up in point 2) of the list of differences
> > sent out.
> >
> > Regards,
> > Karim
> >


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 21 17:17:31 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14567
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Nov 2000 17:17:30 -0500 (EST)
Received: from standards (47.234.32.16:1205) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8E35@standards.nortelnetworks.com>; Tue, 21 Nov 2000 16:58:48 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 124696 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 16:58:47
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:33456) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB8E33@standards.nortelnetworks.com>; Tue, 21 Nov 2000
          16:58:46 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id JAA03007 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 22 Nov 2000 09:12:13
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id JAA19748 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 22 Nov 2000 09:15:04
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBDW099>; Wed, 22 Nov 2000 09:15:19 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613E45@eaubrnt018.epa.ericsson.se>
Date:         Wed, 22 Nov 2000 09:15:18 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
              hes
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> > Pat and Karim,
> >
> > Would you mind giving me a few examples of those wireless networks
> described
> > in the below?
>
> CDMA and 802.11 are two examples where a mobile is instructed that it
> being
> handed off. The mobile does not have any "spare" time to send packets to
> assist in the handoff process.
>
        => To be fair we should also say that in 802.11 the FA wouldn't
        know either since it is not colocated with the AP. Or at least
        that is the case in all WLAN configurations I've seen.

        Regarding CDMA, there is more to it depending on which
        CDMA system.
        I agree that there is no time after the handoff command but there
        is certainly time right before that.
        There is a lot of messaging that goes on during the handoff
procedure
        and before the handoff command. At least this is the case in 2 CDMA
        systems that use MIP.

        Hesham

> > I'd just like to know about it.
> > Thanks.
> >
> > Eunsoo
> >
> > ----- Original Message -----
> > From: "Karim El-Malki (ERA)" <Karim.El-Malki@ERA.ERICSSON.SE>
> > To: <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
> > Sent: Friday, October 06, 2000 12:02 PM
> > Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff
> approac
> > hes
> >
> >
> > > >
> > > > I believe that Pete's common on real time has to do with the
> > > > current state of
> > > > some cellular networks. In some of these technologies, the
> > > > Mobile gets a
> > > > message, informing it to do a handoff. There is no extra time
> > > > for the mobile
> > > > to register. Tom Hiller stated this on the v4 handoff design
> > > > team conference
> > > > call, but I believe you weren't on that particular call.
> > >
> > > I am aware of this and am not disagreeing.
> > > My point is that the registration can be done before the Mobile
> > > gets the L2 message informing it to handoff. Thus we require
> > > interworking between L2 and L3 on the network-side (which is
> > > needed anyway) such that L3 registration can occur at the same
> > > time as L2 signalling and such that the L2 handoff message is
> > > sent after the L3 registration. As I wrote in my reply to Pete,
> > > this is what is summed up in point 2) of the list of differences
> > > sent out.
> > >
> > > Regards,
> > > Karim
> > >


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 21 19:48:47 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04718
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Nov 2000 19:48:47 -0500 (EST)
Received: from standards (47.234.32.16:3672) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8F21@standards.nortelnetworks.com>; Tue, 21 Nov 2000 19:29:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 125018 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 19:29:57
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB8F1F@standards.nortelnetworks.com>; Tue, 21 Nov 2000 19:29:56
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Tue, 21 Nov 2000 16:46:00 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <XLYYQGR2>; Tue, 21 Nov 2000 16:46:48 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA81C9BCF@red-msg-06.redmond.corp.microsoft.com>
Date:         Tue, 21 Nov 2000 15:13:19 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] AMOBILE-IPA New draft for Mobile IPv6
X-To:         Mattias Pettersson <mattias.pettersson@era.ericsson.se>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> > I'm still looking for clarification of the issues I raised
> in the below
> > email. I've only seen one response (thanks Francis) and it
> left me with the
> > impression that there isn't consensus on these questions,
> which are rather
> > important for interoperability.
> >
> I would go for Home Address option between Routing Header and Fragment
> Header. IMHO this is the logical place to put it with respect to the
> order headers are processed and with no respect to existing
> implementations of whatsoever protocol.
>
> If we have a chance to put it where it should belong, let's
> do it before
> specs get more fixed.

As you know, I disagree about the placement of the Home Address option. But
your response is a non sequiter. I'll reproduce below the issues to which I
was referring. They have to do with policy/IKE interactions, not header
placement.

Thanks,
Rich

> -----Original Message-----
> From: Richard Draves
> Sent: Monday, November 13, 2000 9:06 PM
> To: Mobile IP (E-mail); IPsec (E-mail)
> Subject: mobile IPv6 & IPsec policies
>
>
> I have some questions about the interactions between mobile
> IPv6 and IPsec policy selection (SPD lookup) and IKE (SA
> negotiation) in draft-ietf-mobileip-ipv6-12, especially
> sections 4.4 and 10.2. If this is all obvious to others then
> perhaps the draft could be clarified. It's not obvious to me
> and I don't know enough about IPsec & IKE to be certain of
> the answers.
>
> I believe the draft says/implies: the security policies on
> the mobile node do not usually change when the mobile node
> moves, and policy lookups use home addresses, not care-of addresses.
>
> A. What policy selectors should be used when
> sending/receiving a Binding Update? Section 10.2 says:
>
>     -  As part of outbound packet processing in IP, the packet is
>        compared against the IPsec Security Policy Database (SPD) to
>        determine what processing is required for the packet [13].
>
>     -  As a special case for Mobile IP, if a Binding Update or
>        Binding Acknowledgement is being included in the packet, IPsec
>        authentication, integrity protection, and replay
> protection MUST
>        be applied to the packet [13, 11, 12], as defined in
> Section 4.4.
>        If the SPD check above has already indicated that
> authentication
>        and replay protection are required, this processing is
> sufficient
>        for the Mobile IP requirement that all packets
> containing Binding
>        Updates or Binding Acknowledgements be authenticated
> and covered
>        by replay protection.  Otherwise, an implementation can force
>        the required IPsec processing on this individual packet by, for
>        example, creating a temporary SPD entry for the
> handling of this
>        packet.
>
> Suppose you are piggy-backing a Binding Update on a TCP or
> UDP packet, but the selectors find a policy of "no IPsec
> needed" in the SPD. Then Mobile IPv6 is saying, you should
> negotiate and use an SA anyway, because the Binding Update
> needs to be protected. The suggestion is to create a
> temporary SPD entry. What should this temporary SPD entry
> contain? What transforms should be proposed in the ensuing
> IKE negotation? What if there is a policy, but it doesn't
> provide the required protections - if you try to negotiate an
> SA with IKE for transforms that aren't in the policy, isn't
> the correspondent likely to reject the proposals when they
> don't match its policy?
>
> Suppose this is a "naked" Binding Update, not piggy-backed on
> a TCP or UDP packet. What selectors should be used in the
> policy lookup? Should there be a policy lookup at all, or
> should you instead try to find & use any suitable existing SA
> between the two machines? It seems like a naked Binding
> Update should reuse if possible an existing SA between the
> two machines.
>
>
> B. Suppose the mobile node's home is in the same organization
> as the correspondent node (ie normally no IPsec needed for
> communication between home location & correspondent), but the
> mobile node is away from home. In fact there is a Security
> Gateway between the mobile node and the correspondent node,
> and the mobile node needs to use one SA to communicate with
> the SG (say ESP tunnel-mode) and a second SA (say
> transport-mode AH) to send binding-updates through to the
> correspondent node. A policy lookup on the mobile node based
> solely on the home address will not work because the result
> will be "no IPsec needed". Even if you force the use of IPsec
> to protect the Binding Updates (as discussed above), you
> won't know to negotiate a tunnel-mode SA and communicate via the SG.
>
> One possibility (that I like) is that Mobile IPv6 effectively
> mandates that policies that need communication via a security
> gateway must be implemented in the routing table via a tunnel
> interface, instead of in the SPD. However, mandating this
> style of implementation for security gateway policies would
> be a departure from the base IPsec standard as I understand
> it. For one thing, because routing table lookups are usually
> based just on destination address and don't take into account
> the other IPsec selectors, this would limit the kinds of
> policies that you could use.
>
> An alternative would be to say the mobile node does TWO
> lookups in the SPD, one using its home address and another
> using its care-of address, and merges the resulting policies
> that it gets from those two lookups. Actually it gets more
> complicated, because there might be an HA->CoA mapping for
> the destination as well as the source address. The tunnel
> interface approach to dealing with security gateways seems simpler.
>
> Thanks,
> Rich
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 21 20:54:01 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13936
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Nov 2000 20:54:01 -0500 (EST)
Received: from standards (47.234.32.16:3466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8FA0@standards.nortelnetworks.com>; Tue, 21 Nov 2000 20:35:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 125191 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 20:35:12
          -0500
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBB8F9E@standards.nortelnetworks.com>; Tue, 21 Nov 2000 20:35:11
          -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Tue, 21 Nov 2000 16:46:17 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <XLYYQGVJ>; Tue, 21 Nov 2000 16:47:05 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA81C9BD1@red-msg-06.redmond.corp.microsoft.com>
Date:         Tue, 21 Nov 2000 15:23:23 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile IP v6:draft-ietf-mobileip-ip
              v6-13.txt
X-To:         Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I have two main issues with draft-ietf-mobileip-ipv6-13.txt.

1. The draft is very clear & unambiguous (which is good) about the IPsec
headers, but I still respectfully disagree. Mandating AH to protect Binding
Updates is too restrictive. It is quite feasible to allow for either AH or
ESP. In recent discussions of this on the ipsec list, a couple other people
(Henry Spencer [henry@spsystems.net], Markku Savela
[Markku.Savela@research.nokia.com]) have agreed with me on this point.

2. The draft is insufficiently clear about the interactions between Mobile
IPv6 and IPsec policy (SPD) and IKE negotiations. I think there's very
little chance that two implementations of this draft would interoperate out
of the box because of this. (If two implementors get together and jointly
configure their policy databases, I think this problem can be overcome. But
that's not very satisfactory for deployment.) See my mail of the last couple
days on this topic for more detail.

Rich

> -----Original Message-----
> From: Roberts Philip-qa3445
> [mailto:Philip_Roberts-qa3445@email.mot.com]
> Sent: Tuesday, November 21, 2000 7:28 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: [MOBILE-IP] WG Last Call: Mobile IP
> v6:draft-ietf-mobileip-ipv6-13.txt
>
>
> Folks,
>
> This is a Mobile IP WG last call for the I-D
> draft-ietf-mobileip-ipv6-13.txt - Generalized NAI Extension
> (GNAIE). This draft will be sent to the IESG requesting a proposed
> standard status to be associated with it at the end of the last call
> period. Please send your comments to the WG discussion list.
>
> Although the draft has been submitted to the Internet
> Directory it has not
> appeared on the website yet.  In the meantime it can be viewed at:
> http://www.diameter.org/charliep/txt/mobilev6/mobilev6.txt
>
> WG Last call issued on : Nov 21, 2000
> Expires on : December 8, 2000
>
> Basavaraj Patil
> Phil Roberts
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 21 21:09:17 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15802
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Nov 2000 21:09:17 -0500 (EST)
Received: from standards (47.234.32.16:3466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8FE6@standards.nortelnetworks.com>; Tue, 21 Nov 2000 20:50:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 125288 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 20:50:25
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBB8FE4@standards.nortelnetworks.com>;
          Tue, 21 Nov 2000 20:50:24 -0500
Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id TAA05799; Tue, 21 Nov 2000 19:07:18
          -0700 (MST)
Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by
          engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          SAA25749; Tue, 21 Nov 2000 18:07:18 -0800 (PST)
Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id
          eAM26BQ10982; Tue, 21 Nov 2000 18:06:12 -0800 (PST)
X-Sun-Charset: US-ASCII
Approved-By:  Mohan Parthasarathy <Mohan.Parthasarathy@ENG.SUN.COM>
Message-ID:  <200011220206.eAM26BQ10982@locked.eng.sun.com>
Date:         Tue, 21 Nov 2000 18:06:12 -0800
Reply-To: Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com>
Subject:      Re: [MOBILE-IP] AMOBILE-IPA New draft for Mobile IPv6
X-To:         richdr@microsoft.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

 > >
> >
> > I have some questions about the interactions between mobile
> > IPv6 and IPsec policy selection (SPD lookup) and IKE (SA
> > negotiation) in draft-ietf-mobileip-ipv6-12, especially
 > >
> > Suppose you are piggy-backing a Binding Update on a TCP or
> > UDP packet, but the selectors find a policy of "no IPsec
> > needed" in the SPD. Then Mobile IPv6 is saying, you should
> > negotiate and use an SA anyway, because the Binding Update
> > needs to be protected. The suggestion is to create a
> > temporary SPD entry. What should this temporary SPD entry
> > contain? What transforms should be proposed in the ensuing
> > IKE negotation? What if there is a policy, but it doesn't
> > provide the required protections - if you try to negotiate an
> > SA with IKE for transforms that aren't in the policy, isn't
> > the correspondent likely to reject the proposals when they
> > don't match its policy?
> >
Why is this any different from any two nodes outside the context
of mobile-ip talking to each other ? Today if two nodes need
to communicate using IPsec and if the policy does not match,
it can't communicate.

Are you saying that we should mandate some policy on how
the binding updates should be protected ?

> > Suppose this is a "naked" Binding Update, not piggy-backed on
> > a TCP or UDP packet. What selectors should be used in the
> > policy lookup? Should there be a policy lookup at all, or
> > should you instead try to find & use any suitable existing SA
> > between the two machines? It seems like a naked Binding
> > Update should reuse if possible an existing SA between the
> > two machines.
> >
I agree that we need new selectors. e.g. based on the destination
option type.

> >
> > B. Suppose the mobile node's home is in the same organization
> > as the correspondent node (ie normally no IPsec needed for
> > communication between home location & correspondent), but the
> > mobile node is away from home. In fact there is a Security
> > Gateway between the mobile node and the correspondent node,
> > and the mobile node needs to use one SA to communicate with
> > the SG (say ESP tunnel-mode) and a second SA (say
> > transport-mode AH) to send binding-updates through to the
> > correspondent node. A policy lookup on the mobile node based
> > solely on the home address will not work because the result
> > will be "no IPsec needed". Even if you force the use of IPsec
> > to protect the Binding Updates (as discussed above), you
> > won't know to negotiate a tunnel-mode SA and communicate via the SG.
> >
> > One possibility (that I like) is that Mobile IPv6 effectively
> > mandates that policies that need communication via a security
> > gateway must be implemented in the routing table via a tunnel
> > interface, instead of in the SPD. However, mandating this
> > style of implementation for security gateway policies would
> > be a departure from the base IPsec standard as I understand
> > it. For one thing, because routing table lookups are usually
> > based just on destination address and don't take into account
> > the other IPsec selectors, this would limit the kinds of
> > policies that you could use.
> >
I understand your concern and the complexity of all this stuff.
But, what you are describing is just how nodes
agree on common policy, how to discover SG etc. All this
should be addressed by IPsec working group eventually. So,
why should this be addressed by mobile IPv6 draft ?

I think how the mobile node and HA/CN communicate with each other
securely can be written as a separate informational draft.


-mohan

> > An alternative would be to say the mobile node does TWO
> > lookups in the SPD, one using its home address and another
> > using its care-of address, and merges the resulting policies
> > that it gets from those two lookups. Actually it gets more
> > complicated, because there might be an HA->CoA mapping for
> > the destination as well as the source address. The tunnel
> > interface approach to dealing with security gateways seems simpler.
> >
> > Thanks,
> > Rich
> >
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 21 22:28:55 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26023
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Nov 2000 22:28:54 -0500 (EST)
Received: from standards (47.234.32.16:4348) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9071@standards.nortelnetworks.com>; Tue, 21 Nov 2000 22:10:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 125486 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 22:10:04
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBB906F@standards.nortelnetworks.com>;
          Tue, 21 Nov 2000 22:10:04 -0500
Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id UAA01289 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 21 Nov 2000 20:26:58
          -0700 (MST)
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,v1.7) with ESMTP id
          TAA08695 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 21 Nov
          2000 19:26:57 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id TAA21403 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 21 Nov 2000 19:26:56
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Patrice Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.974863445.28687.pcalhoun@nasnfs>
Date:         Tue, 21 Nov 2000 19:24:05 -0800
Reply-To: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      [MOBILE-IP] Pro-active Foreign Agent version 03 preview avaiable
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

All,

We have just submitted version 03 of the proactive Foreign Agent I-D to the
secretariat. A preview of the I-D can be found at www.diameter.org.

This revision addressed some comments that were received on the list. However,
we were not able to utilize all of the comments received. Specifically, one
comment was to make exclusive use of the Binding messages. However, after
reading the route optimization I-D closer, it became apparent that our I-D
made use of the Binding Update message in the inverse direction (not the way
the route opt I-D intended the message to be used). Therefore we had to create
our own messages, called the Handoff-Request/Reply.

Comments are welcomed and encouraged,

PatC (done right on time to leave for vacation)


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov 22 08:55:47 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19995
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 22 Nov 2000 08:55:47 -0500 (EST)
Received: from standards (47.234.32.16:3114) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB94BC@standards.nortelnetworks.com>; Wed, 22 Nov 2000 8:36:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 126935 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Nov 2000 08:36:33
          -0500
Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBB94BA@standards.nortelnetworks.com>; Wed, 22 Nov 2000
          8:36:32 -0500
Received: from p-grive.issy.cnet.fr ([139.100.0.85]) by p-biset.issy.cnet.fr
          with SMTP (Microsoft Exchange Internet Mail Service Version
          5.5.2650.21) id WZ815GQ2; Wed, 22 Nov 2000 14:36:27 +0100
Received: from rd.francetelecom.fr (p-dico.issy.cnet.fr [139.100.18.135]) by
          p-grive.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id VC12YZVA; Wed, 22 Nov 2000 14:36:27
          +0100
X-Mailer: Mozilla 4.7 [fr] (WinNT; U)
X-Accept-Language: fr
MIME-Version: 1.0
References: <7695E2F6903F7A41961F8CF888D87EA81C9BD1@red-msg-06.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Approved-By:  Jean-Michel COMBES <jeanmichel.combes@RD.FRANCETELECOM.FR>
Message-ID:  <3A1BCC4E.D00423AE@rd.francetelecom.fr>
Date:         Wed, 22 Nov 2000 14:38:22 +0100
Reply-To: Jean-Michel COMBES <jeanmichel.combes@rd.francetelecom.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Jean-Michel COMBES <jeanmichel.combes@rd.francetelecom.fr>
Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile IP
              v6:draft-ietf-mobileip-ipv6-13.txt
X-To:         Richard Draves <richdr@microsoft.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

Hi,

Richard Draves a écrit :

> I have two main issues with draft-ietf-mobileip-ipv6-13.txt.
>
> 1. The draft is very clear & unambiguous (which is good) about the IPsec
> headers, but I still respectfully disagree. Mandating AH to protect Binding
> Updates is too restrictive.

JMC :
I agree that's too restrictive perhaps.

> It is quite feasible to allow for either AH or
> ESP.

JMC :
Agree,
- AH/transport
or
- ESP/tunnel (with null encryption)

> In recent discussions of this on the ipsec list, a couple other people
> (Henry Spencer [henry@spsystems.net], Markku Savela
> [Markku.Savela@research.nokia.com]) have agreed with me on this point.

JMC :
Perhaps, it would be better just to say in the draft that BU and BAck MUST be
authenticated without specifying how, everyone choosing his policy (see above).

Regards.

--

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : jeanmichel.combes@rd.francetelecom.fr
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 24 08:36:17 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10659
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 24 Nov 2000 08:36:16 -0500 (EST)
Received: from standards (47.234.32.16:2631) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBA088@standards.nortelnetworks.com>; Fri, 24 Nov 2000 8:17:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 130833 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Nov 2000 08:17:09
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBA086@standards.nortelnetworks.com>; Fri, 24 Nov 2000 8:17:08
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAODXnb26493; Fri, 24 Nov 2000 14:33:50 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr
          [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with
          ESMTP id OAA23639; Fri, 24 Nov 2000 14:33:49 +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.9.3/8.9.3) with
          ESMTP id OAA29223; Fri, 24 Nov 2000 14:36:48 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011241336.OAA29223@givry.rennes.enst-bretagne.fr>
Date:         Fri, 24 Nov 2000 14:36:48 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] Comment Please: Placement for Home Address option
              header
X-To:         Richard Draves <richdr@microsoft.com>
X-cc:         Charlie Perkins <charliep@iprg.nokia.com>,
              Markku Savela <Markku.Savela@research.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Mon, 20 Nov 2000 08:31:28 PST. 
              <7695E2F6903F7A41961F8CF888D87EA801469227@red-msg-06.redmond.corp.microsoft.com>

 In your previous mail you wrote:

   > => do you propose to change all IPsec implementations?

   Adding mobile node support will require some change to all implementations.

=> the purpose of the mobile IPv6 specs is to require minimal changes
(as for any new specs).

   It's a question of how much changes. For your implementation, you're saying
   that allowing the Home Address option to appear after the IPsec headers will
   require substantial change.

=> no, I am saying this will require substantial change to all the
implementations I have read the code (KAME, NRL, OpenBSD, FreeS/WAN) with
the exception of KAME (more because KAME is not very compliant than
because of a clever implementation :-). I have no access to proprietary
source codes then I've posted the question in the IPsec mailing list...

   For my implementation (and Markku's
   implementation), it does not require much change.

=> 2 examples (or 4) are not enough to have a good idea of the common
practice (or of the rationale behind RFC 2401).

   > => lazy-evaluation is not an option if you'd like to support
   > the multiple
   > IPsec header case.

   Not true. Again, I have an existence proof.

=> have you tried your code with multiple IPsec headers, for instance
an AH followed by an ESP (with confidentiality, a common combinaison)?
I'd like to know you can get the home address from a header in a ciphered
payload...

Francis.Dupont@enst-bretagne.fr

PS: the discussion is moving to the IPsec mailing list.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 24 09:43:35 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27818
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 24 Nov 2000 09:43:34 -0500 (EST)
Received: from standards (47.234.32.16:3798) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBA0F3@standards.nortelnetworks.com>; Fri, 24 Nov 2000 9:24:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 130977 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Nov 2000 09:24:40
          -0500
Received: from esebh01nok.ntc.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBA0F1@standards.nortelnetworks.com>; Fri, 24 Nov 2000 9:24:40
          -0500
Received: by esebh01nok with Internet Mail Service (5.5.2652.78) id <XRA8AKKX>;
          Fri, 24 Nov 2000 16:41:40 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  henry.haverinen@NOKIA.COM
Message-ID:  <6D1A8E7871B9D211B3B00008C7490AA504E62364@treis03nok>
Date:         Fri, 24 Nov 2000 16:41:36 +0200
Reply-To: henry.haverinen@nokia.com
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Henry Haverinen <henry.haverinen@nokia.com>
Subject:      [MOBILE-IP] New revision of the gsmsim draft
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hello,

I have submitted a revised Internet Draft "GSM SIM Authentication
and Key Generation for Mobile IP" to the Internet Draft directories.
The draft is also available at the following URL:
http://www.cs.tut.fi/~h137747/draft-haverinen-mobileip-gsmsim-01.txt

The new revision is intended to address the issues in the -00 revision
discussed on this mailing list. It also uses the MN-AAA Authentication
extension, so that the mobility agents don't need to be GSM SIM aware.

Any comments are most welcome!

Regards,
Henry


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 24 10:02:45 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02049
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 24 Nov 2000 10:02:45 -0500 (EST)
Received: from standards (47.234.32.16:3798) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBA12E@standards.nortelnetworks.com>; Fri, 24 Nov 2000 9:43:56 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 131058 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Nov 2000 09:43:56
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBA12C@standards.nortelnetworks.com>; Fri, 24 Nov 2000 9:43:55
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAOF0lb19485; Fri, 24 Nov 2000 16:00:47 +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 QAA26852; Fri, 24 Nov 2000 16:00:47 +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.9.3/8.9.3) with
          ESMTP id QAA29642; Fri, 24 Nov 2000 16:03:46 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011241503.QAA29642@givry.rennes.enst-bretagne.fr>
Date:         Fri, 24 Nov 2000 16:03:46 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] Placement for Binding Update and Home Address opt
              ions
X-To:         Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Mon, 20 Nov 2000 15:35:30 CST. 
              <0DF9920C9AD8D211AB0C0008C7CF1C9A0498FCB1@il27exm02.cig.mot.com>

 In your previous mail you wrote:

   Francis, Sorry for the delay, see my comments/ questions below:
   --------------------
    In your previous mail you wrote:

      => I agree, home address and tunnel encapsulation limit between routing
      and fragment, all other destination options (binding XXX) after ESP.

         Comments?

      Does this mean that we are leaving the home address information
      without confidentiality protection?

   => you can't easily make the home address confidential because the ESP
   processing needs to know the real source (ie. the home address) in
   the SA selector phase :
    - or you hack your IPsec implementation in order to get the home address
      and to use it
    - or you hack your IPsec implementation in order to skip the SA selector
      phase but you can introduce a security problem
    - or you build the SA with the care-of address and you have to rebuild
      it at each movement
   (then it is not easy as I've said :-).
   BTW why do you want to hide the home address information?
   ----------------


   I don't want to rock the boat, specially a titanic like IPSec, so I would
   safely assume that the first and second options are out of question.

=> Richard Draves argues for the first option and we are trying to know
if this will be a big problem or not for IPsec implementors.

   I also understand the importance of having the home address, on which the SA
   lookup and verification is based on, in the clear at the security check
   points, whether it is a gateway, firewall or the end unit.

=> yes, firewalls don't like confidentiality... I don't know what is the
most important, firewalls or confidentiality (your following arguments
are obviously pros for confidentiality).

   I guess hiding the home address cannot be required. I don't know how much
   the service providers want to protect their network topologies?
   But what if a mobile node desires to have location privacy (c/o of address
   or home address), like asking your phone company not to list your home phone
   number, or cell phone number. Isn't this a feature that a lot of people
   would want?

=> perhaps but in this case the only good solution is a secure bidirectional
tunnel with the home agent. This should be an option for mobile IPv6 but
I believe we should get the optimized mobile IPv6 first.

   I don't exactly know, how a mobile handles the binding requests? There is no
   requirement for authentication for binding requests?

=> a mobile answers to a binding request only if it has the relevant entry
in its binding cache (then there is no security constraints).

   So is there enough
   protection for the binding update, so intruders would not be able to get
   mobile's home and c/o address by sending a binding request to its home
   address? (or maybe its old c/o)

=> if the attacker doesn't know its home address it can do nothing,
if it knows then the protection relies on the mobile node policy
(for instance it should not try to optimize the routing).

   Hope I am not too far out in the woods %-)

=> no, security is full of trade-off issue and we don't want an insecure
mobility.

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 24 12:10:01 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01848
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 24 Nov 2000 12:10:00 -0500 (EST)
Received: from standards (47.234.32.16:3792) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBA25F@standards.nortelnetworks.com>; Fri, 24 Nov 2000 11:51:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 131465 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Nov 2000 11:51:12
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBA25D@standards.nortelnetworks.com>; Fri, 24 Nov 2000 11:51:11
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAOH6vb26669; Fri, 24 Nov 2000 18:06:58 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr
          [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with
          ESMTP id SAA01488; Fri, 24 Nov 2000 18:06:57 +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.9.3/8.9.3) with
          ESMTP id SAA30456; Fri, 24 Nov 2000 18:09:55 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011241709.SAA30456@givry.rennes.enst-bretagne.fr>
Date:         Fri, 24 Nov 2000 18:09:55 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] RFC 2401 section 5.2.1
X-To:         Henry Spencer <henry@spsystems.net>
X-cc:         itojun@iijlab.net, ipsec@lists.tislabs.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Tue, 21 Nov 2000 10:35:14 EST. 
              <Pine.BSI.3.91.1001121103300.181B-100000@spsystems.net>

 In your previous mail you wrote:

   On Wed, 22 Nov 2000 itojun@iijlab.net wrote:
   >    most of routing protocol needs to somehow protect IPv6 source address,
   >    as they will use (peers') IPv6 source address as the nexthop router
   >    information...

   Many of the death-to-AH enthusiasts also favoring killing transport mode

=> I know... but IMHO the tunnel mode is not very primitive, ie. this is
tunnel plus transport plus clarifications about inner/outer addresses.

   and doing everything with tunnel mode, in which case the inner headers --
   the ones that would be visible to applications -- are fully protected.
   (Notably, they can be encrypted as well as authenticated, if desired.)

=> VPN is not the only usage of IPsec and transport mode is better for
end-to-end security.

About the tunnel mode, for IPv6 there is an important implementation choice:
to use a policy or to use an interface (with link-local addresses,
neighbor discovery, ...).

Regards

Francis.Dupont@enst-bretagne.fr

PS: there are many votes about AH in the past, AH is still alive
(we voted to keep it) and needed by many IPv6 protocols (cf Itojun's mail).


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 24 12:36:48 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07735
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 24 Nov 2000 12:36:47 -0500 (EST)
Received: from standards (47.234.32.16:2081) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBA29D@standards.nortelnetworks.com>; Fri, 24 Nov 2000 12:18:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 131552 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Nov 2000 12:18:00
          -0500
Received: from spsystems.net by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBA29B@standards.nortelnetworks.com>;
          Fri, 24 Nov 2000 12:18:00 -0500
Received: (from henry@localhost) by spsystems.net (8.9.3/8.9.3) id MAA24375;
          Fri, 24 Nov 2000 12:34:48 -0500 (EST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved-By:  Henry Spencer <henry@SPSYSTEMS.NET>
Message-ID:  <Pine.BSI.3.91.1001124123008.24306B-100000@spsystems.net>
Date:         Fri, 24 Nov 2000 12:34:48 -0500
Reply-To: Henry Spencer <henry@spsystems.net>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Henry Spencer <henry@spsystems.net>
Subject:      Re: [MOBILE-IP] RFC 2401 section 5.2.1
X-To:         Francis Dupont <Francis.Dupont@enst-bretagne.fr>
X-cc:         ipsec@lists.tislabs.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200011241709.SAA30456@givry.rennes.enst-bretagne.fr>

On Fri, 24 Nov 2000, Francis Dupont wrote:
> => VPN is not the only usage of IPsec and transport mode is better for
> end-to-end security.

How is it "better"?  Aside from slightly reducing the byte count on the
wire, I mean?

We use tunnel mode for end-to-end security quite routinely.  In fact, it
seems to us that tunnel mode actually gives slightly higher security,
because it obscures whether the communication really *is* end-to-end or is
being done on behalf of other hosts.

> PS: there are many votes about AH in the past, AH is still alive...

So far, yes.

> ...and needed by many IPv6 protocols (cf Itojun's mail).

That is exactly the question:  *should* those protocols be relying on the
quirks of AH?  It would be better if they could also work with ESP.

                                                          Henry Spencer
                                                       henry@spsystems.net


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 24 18:02:46 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19412
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 24 Nov 2000 18:02:45 -0500 (EST)
Received: from standards (47.234.32.16:1419) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBA43B@standards.nortelnetworks.com>; Fri, 24 Nov 2000 17:43:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 132090 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Nov 2000 17:43:46
          -0500
Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBA439@standards.nortelnetworks.com>; Fri, 24 Nov 2000 17:43:46
          -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id SAA18898; Fri, 24 Nov 2000 18:00:46
          -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Approved-By:  scoya@CNRI.RESTON.VA.US
Message-ID:  <200011242300.SAA18898@ietf.org>
Date:         Fri, 24 Nov 2000 18:00:45 -0500
Reply-To: Internet-Drafts@ietf.org
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject:      [MOBILE-IP] I-D ACTION:draft-decarolis-qoshandover-00.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--NextPart

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


        Title           : QoS-Aware Handover for Mobile IP: Secondary Home Agent
        Author(s)       : A. De Carolis
        Filename        : draft-decarolis-qoshandover-00.txt
        Pages           : 15
        Date            : 22-Nov-00

This document specifies an extension to the Mobile IPv6 [1]  Protocol
that enables a Mobile Node to  perform a particular kind of  Handover
called QoS-Aware Handover. The peculiarity  of this kind of  Handover
is that it  allows the  Mobile Node to  change the  current point  of
attachment to  the Internet  without loosing  the  QoS, even  if  the
Handover process  takes a  long time.  This extension  is part  of  a
larger effort toward the integration of Mobility and QoS over IP.
This document  contains also  a procedure  that COULD  be used  by  a
Mobile Node to support such a QoS-Aware Handover.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-decarolis-qoshandover-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-decarolis-qoshandover-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:     <20001122145851.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-decarolis-qoshandover-00.txt

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

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

--OtherAccess--

--NextPart--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Nov 24 18:58:12 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01315
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 24 Nov 2000 18:58:11 -0500 (EST)
Received: from standards (47.234.32.16:1250) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBA48C@standards.nortelnetworks.com>; Fri, 24 Nov 2000 18:39:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 132202 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Nov 2000 18:39:25
          -0500
Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBA48A@standards.nortelnetworks.com>; Fri, 24 Nov 2000 18:39:25
          -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id SAA01004; Fri, 24 Nov 2000 18:56:24
          -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Approved-By:  scoya@CNRI.RESTON.VA.US
Message-ID:  <200011242356.SAA01004@ietf.org>
Date:         Fri, 24 Nov 2000 18:56:24 -0500
Reply-To: Internet-Drafts@ietf.org
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject:      [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-optim-10.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--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           : Route Optimization in Mobile IP
        Author(s)       : C. Perkins, D. Johnson
        Filename        : draft-ietf-mobileip-optim-10.txt
        Pages           : 25
        Date            : 22-Nov-00

Using the base Mobile IP protocol, all datagrams destined to a mobile
node are routed through that mobile node's home agent, which then
tunnels each datagram to the mobile node's current location.  This
document defines Route Optimization messages and extensions to the
base protocol to optimize datagram routing to a mobile node.  Using
these protocol extensions, correspondent nodes may cache the binding
of a mobile node, and then tunnel their datagrams for the mobile node
directly to the care-of address, bypassing the mobile node's home
agent.  Extensions are also provided to allow datagrams in flight
when a mobile node moves, and datagrams sent based on an out-of-date
cached binding, to be forwarded directly to the mobile node's new
binding.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-mobileip-optim-10.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-optim-10.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:     <20001122145508.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-optim-10.txt

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

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

--OtherAccess--

--NextPart--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Nov 25 08:55:51 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15622
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 25 Nov 2000 08:55:50 -0500 (EST)
Received: from standards (47.234.32.16:4617) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBA714@standards.nortelnetworks.com>; Sat, 25 Nov 2000 8:36:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 133088 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 25 Nov 2000 08:36:43
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:42672) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBA712@standards.nortelnetworks.com>; Sat, 25 Nov 2000
          8:36:42 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id AAA23339 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sun, 26 Nov 2000 00:50:18
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id AAA20240 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sun, 26 Nov 2000 00:53:10
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBDZM9Z>; Sun, 26 Nov 2000 00:53:25 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613E70@eaubrnt018.epa.ericsson.se>
Date:         Sun, 26 Nov 2000 00:53:17 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      [MOBILE-IP] new HMIPv6 draft
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi All,

We have submitted an updated HMIPv6 draft.
(draft-iet-mobileip-hmipv6-02)
The draft should be announced soon and will be available on
the INRIA web site sooner.
Here are the main changes from the last revision :

- Clarified the different MAP modes in two separate chapters.
  Basic mode and Extended mode.

- Added a new chapter to show a comparison between
  the 2 modes.

- Added two more mechanisms for MAP discovery. All methods
  are still using the same MAP option.

- Added a new chapter on MAP selection by the MN for both
  static and dynamic hierarchies.

- Security considerations chapter.

Apart from the new MAP discovery methods, the protocols or ideas
in the last revision are still the same but they were expanded and
explained a bit more.

Regards,
Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 05:23:45 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08751
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 05:23:44 -0500 (EST)
Received: from standards (47.234.32.16:1275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBAE9E@standards.nortelnetworks.com>; Mon, 27 Nov 2000 5:04:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 135720 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 05:04:12
          -0500
Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBAE9C@standards.nortelnetworks.com>; Mon, 27 Nov 2000 5:04:11
          -0500
Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by
          ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id LAA12207; Mon, 27 Nov
          2000 11:21:21 +0100 (MET)
Received: from inrialpes.fr (localhost [127.0.0.1]) by glandon.inrialpes.fr
          (8.8.7/8.8.5) with ESMTP id LAA14954; Mon, 27 Nov 2000 11:21:20 +0100
          (MET)
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <4B6BC00CD15FD2119E5F0008C7A419A50C613E70@eaubrnt018.epa.ericsson.se>
Content-Type: multipart/alternative;
              boundary="------------257D23C0927E3AF780A4791F"
Approved-By:  Claude.Castelluccia@INRIALPES.FR
Message-ID:  <3A2235A0.6708ECC@inrialpes.fr>
Date:         Mon, 27 Nov 2000 11:21:20 +0100
Reply-To: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
Subject:      Re: [MOBILE-IP] new HMIPv6 draft
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

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


FYI the draft can be retrieved at:
http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-02.txt

enjoy it ;-)

regards,
Claude.

"Hesham Soliman (EPA)" wrote:

> Hi All,
>
> We have submitted an updated HMIPv6 draft.
> (draft-iet-mobileip-hmipv6-02)
> The draft should be announced soon and will be available on
> the INRIA web site sooner.
> Here are the main changes from the last revision :
>
> - Clarified the different MAP modes in two separate chapters.
>   Basic mode and Extended mode.
>
> - Added a new chapter to show a comparison between
>   the 2 modes.
>
> - Added two more mechanisms for MAP discovery. All methods
>   are still using the same MAP option.
>
> - Added a new chapter on MAP selection by the MN for both
>   static and dynamic hierarchies.
>
> - Security considerations chapter.
>
> Apart from the new MAP discovery methods, the protocols or ideas
> in the last revision are still the same but they were expanded and
> explained a bit more.
>
> Regards,
> Hesham

--

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



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>FYI&nbsp;the draft can be retrieved at:
<br><A HREF="http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-02.txt">http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-02.txt</A>
<p>enjoy it ;-)
<p>regards,
<br>Claude.
<p>"Hesham Soliman (EPA)" wrote:
<blockquote TYPE=CITE>Hi All,
<p>We have submitted an updated HMIPv6 draft.
<br>(draft-iet-mobileip-hmipv6-02)
<br>The draft should be announced soon and will be available on
<br>the INRIA web site sooner.
<br>Here are the main changes from the last revision :
<p>- Clarified the different MAP modes in two separate chapters.
<br>&nbsp; Basic mode and Extended mode.
<p>- Added a new chapter to show a comparison between
<br>&nbsp; the 2 modes.
<p>- Added two more mechanisms for MAP discovery. All methods
<br>&nbsp; are still using the same MAP option.
<p>- Added a new chapter on MAP selection by the MN for both
<br>&nbsp; static and dynamic hierarchies.
<p>- Security considerations chapter.
<p>Apart from the new MAP discovery methods, the protocols or ideas
<br>in the last revision are still the same but they were expanded and
<br>explained a bit more.
<p>Regards,
<br>Hesham</blockquote>

<pre>--&nbsp;

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

--------------257D23C0927E3AF780A4791F--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 14:01:31 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29434
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 14:01:31 -0500 (EST)
Received: from standards (47.234.32.16:2671) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB120@standards.nortelnetworks.com>; Mon, 27 Nov 2000 13:42:10 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 136584 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 13:42:09
          -0500
Received: from u-mail.rd.francetelecom.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBB11E@standards.nortelnetworks.com>; Mon, 27 Nov 2000 13:42:09
          -0500
Received: by u-mail.rd.francetelecom.com with Internet Mail Service
          (5.5.2448.0) id <XXSWB915>; Mon, 27 Nov 2000 10:59:21 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C058A4.25C8489C"
Approved-By:  HUYLEBROECK Jeremy / FTR&D
              <jeremy.huylebroeck@RD.FRANCETELECOM.COM>
Message-ID:  <337055FBC675D311A85D00508B5A9C4F7FB447@u-mail.rd.francetelecom.com>
Date:         Mon, 27 Nov 2000 10:59:19 -0800
Reply-To: HUYLEBROECK Jeremy / FTR&D              <jeremy.huylebroeck@rd.francetelecom.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: HUYLEBROECK Jeremy / FTR&D              <jeremy.huylebroeck@rd.francetelecom.com>
Subject:      [MOBILE-IP] Nextel Services
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

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

------_=_NextPart_001_01C058A4.25C8489C
Content-Type: text/plain;
        charset="iso-8859-1"

Hi,

I'm involved in a project about Mobile IP in my company, France Telecom R&D.

Is there anybody in this mailing list who had already or who currently use
or know Nextel services ?
Technical and non-technical information would be appreciated.
Thank you.

Regards,

Jeremy Huylebroeck
France Telecom Research & Development, LLC
1000 Marina Blvd., Suite 300
Brisbane, CA  94005
http://www.francetelecom.com/rd
email: jeremy.huylebroeck@rd.francetelecom.com
Telephone: +1 650 875-1541 Direct Dial
Fax: +1 650 875-1505 fax




------_=_NextPart_001_01C058A4.25C8489C
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.2448.0">
<TITLE>Nextel Services</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">I'm involved in a project about Mobile =
IP in my company, France Telecom R&amp;D.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Is there anybody in this mailing list =
who had already or who currently use or know Nextel services ?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Technical and non-technical =
information would be appreciated.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Thank you.</FONT>
</P>

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

<P><I><FONT SIZE=3D2 FACE=3D"Bookman Old Style">Jeremy =
Huylebroeck</FONT></I>
<BR><B><FONT SIZE=3D2 FACE=3D"Garamond">France Telecom Research &amp; =
Development, LLC</FONT></B><I></I><I></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Bookman Old Style">1000 =
Marina Blvd., Suite 300</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Bookman Old =
Style">Brisbane, CA&nbsp; 94005</FONT></I>
<BR><U><B><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Garamond"><A =
HREF=3D"http://www.francetelecom.com/rd" =
TARGET=3D"_blank">http://www.francetelecom.com/rd</A></FONT></B></U>
<BR><FONT SIZE=3D1 FACE=3D"Arial">email:</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT><U></U><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Times New =
Roman">jeremy.huylebroeck@rd.francetelecom.com</FONT></U>
<BR><FONT SIZE=3D1 FACE=3D"Arial">Telephone: +1 650 875-1541 Direct =
Dial</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Arial">Fax: +1 650 875-1505 fax</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C058A4.25C8489C--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 15:37:09 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28630
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 15:37:08 -0500 (EST)
Received: from standards (47.234.32.16:1461) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB17D@standards.nortelnetworks.com>; Mon, 27 Nov 2000 15:17:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 136704 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 15:17:48
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:41294) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBB17B@standards.nortelnetworks.com>; Mon, 27 Nov 2000
          15:17:47 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id HAA20535; Tue,
          28 Nov 2000 07:31:29 +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id HAA19231; Tue, 28
          Nov 2000 07:34:21 +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD5PSA>; Tue, 28 Nov 2000 07:34:38 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613E8A@eaubrnt018.epa.ericsson.se>
Date:         Tue, 28 Nov 2000 07:34:36 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
              hes
X-To:         Ajoy Singh <asingh1@email.mot.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

        Ajoy,

>  To be fair we should also say that in 802.11 the FA wouldn't
>  know either since it is not colocated with the AP. Or at least
>  that is the case in all WLAN configurations I've seen.
>
> -> Even in case of CDMA network, FA is not collocated with radio quipment.
> We all agree that some changes are required at network side to
> get trigger at source/target Foreign agent. For example, in case of CDMA
> 2000, we might
> have to make slight modification to R-P interface to send foreign agent
> address
> from PCF to PDSN. Similarly, we have to make some changes where FA is not
> collocated
> with radio equipment. The exact nature of changes will be dependent upon
> the
> specific technology and should be decided by respective SDOs. But I think,
> we should
> not be assuming some thing which will change the handoff model of wireless
> link layer.
> For example, in case of some 802.11 based network, source AP does not know
> about the handoff
> untill link layer handoff is complete. So I think, we can not assume to
> receive
> link layer trigger at source AP and use that to initiate Mobile/IP
> registration
> through old AP.
>
        => You certainly addressed lots of issues. My point was concise
        and straight forward. The proactive approach assumes a certain
        architecture that allows the FA to know that the MN is about to
        move. The handoff control is done completely by the network.
        In some (or many) cases that is not the case. On the other hand
        Fast Handoffs does not assume that, and it allows MN initiation
        or Network initiation. This is simply due to the fact that it
follows RFC2002,
        which was designed in a very generic way, for a good reason.

        I gave WLAN as an example. There are more.
        But there is no need to get into these system specific details.
        As I'm sure you're aware, this is the MIP WG and not MIP for
        cdma2000 or WLAN or something else. So let's try to be generic
        and not confuse people with system specific issues that change
        from one year to another.

        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 18:23:16 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16578
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 18:23:15 -0500 (EST)
Received: from standards (47.234.32.16:1461) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB1DB@standards.nortelnetworks.com>; Mon, 27 Nov 2000 15:48:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 136832 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 15:48:11
          -0500
Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBB1D9@standards.nortelnetworks.com>; Mon, 27 Nov 2000 15:48:10
          -0500
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by
          motgate.mot.com (motgate 2.1) with ESMTP id OAA00602 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 27 Nov 2000 14:05:22
          -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100])
          by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA03139 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 27 Nov 2000 14:05:22
          -0700 (MST)]
Received: from ripcord756 (d50-497f.cig.mot.com [160.47.73.127]) by
          il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2651.58) id WQNKSC9F; Mon, 27 Nov 2000 15:05:19
          -0600
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.00.2314.1300
Approved-By:  Ajoy Singh <asingh1@EMAIL.MOT.COM>
Message-ID:  <NEBBIAJKMGAFBLOHKLJKOEDPCBAA.asingh1@email.mot.com>
Date:         Mon, 27 Nov 2000 15:14:58 -0600
Reply-To: Ajoy Singh <asingh1@email.mot.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ajoy Singh <asingh1@email.mot.com>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
              hes
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>,
              Ajoy Singh <Ajoy_Singh-ASINGH1@email.mot.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4B6BC00CD15FD2119E5F0008C7A419A50C613E8A@eaubrnt018.epa.ericsson.se>
Content-Transfer-Encoding: 7bit

Hello Hesham,
I think, you misunderstood my point. Perhaps I was not clear enough. Please
see my reply.
regards,
ajoy


=> You certainly addressed lots of issues. My point was concise
        and straight forward. The proactive approach assumes a certain
        architecture that allows the FA to know that the MN is about to
        move. The handoff control is done completely by the network.

<AS>  The proactive FA approach assumes source and target trigger which
should cover
      most type of network. Because It is possible to receive link layer
either
        at source or target. Whereas I think, the fast handoff assumes that
        it is possible to register mobile node through old access point
        which is not possible in most of the current networks. For example,
        in case of 802.11 network, it is not possible to register through the
        old access point as only target AP knows about the handoff before
        link layer handoff is complete. So we can not assume something which is not
        doable in present network.  <AS>


        In some (or many) cases that is not the case. On the other hand
        Fast Handoffs does not assume that, and it allows MN initiation
        or Network initiation. This is simply due to the fact that it
follows RFC2002,
        which was designed in a very generic way, for a good reason.

        I gave WLAN as an example. There are more.
        But there is no need to get into these system specific details.
        As I'm sure you're aware, this is the MIP WG and not MIP for
        cdma2000 or WLAN or something else. So let's try to be generic
        and not confuse people with system specific issues that change
        from one year to another.

   <AS> Just to be generic, we have allowed source and target trigger
        approach. We should not make unrealistic assumption such as registering
        through old access point.  <AS>



-----Original Message-----
From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ericsson.com.au]
Sent: Monday, November 27, 2000 2:35 PM
To: 'Ajoy Singh'; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: RE: [MOBILE-IP] Differences between the two MIPv4 handoff
approac hes


        Ajoy,

>  To be fair we should also say that in 802.11 the FA wouldn't
>  know either since it is not colocated with the AP. Or at least
>  that is the case in all WLAN configurations I've seen.
>
> -> Even in case of CDMA network, FA is not collocated with radio quipment.
> We all agree that some changes are required at network side to
> get trigger at source/target Foreign agent. For example, in case of CDMA
> 2000, we might
> have to make slight modification to R-P interface to send foreign agent
> address
> from PCF to PDSN. Similarly, we have to make some changes where FA is not
> collocated
> with radio equipment. The exact nature of changes will be dependent upon
> the
> specific technology and should be decided by respective SDOs. But I think,
> we should
> not be assuming some thing which will change the handoff model of wireless
> link layer.
> For example, in case of some 802.11 based network, source AP does not know
> about the handoff
> untill link layer handoff is complete. So I think, we can not assume to
> receive
> link layer trigger at source AP and use that to initiate Mobile/IP
> registration
> through old AP.
>
        => You certainly addressed lots of issues. My point was concise
        and straight forward. The proactive approach assumes a certain
        architecture that allows the FA to know that the MN is about to
        move. The handoff control is done completely by the network.
        In some (or many) cases that is not the case. On the other hand
        Fast Handoffs does not assume that, and it allows MN initiation
        or Network initiation. This is simply due to the fact that it
follows RFC2002,
        which was designed in a very generic way, for a good reason.

        I gave WLAN as an example. There are more.
        But there is no need to get into these system specific details.
        As I'm sure you're aware, this is the MIP WG and not MIP for
        cdma2000 or WLAN or something else. So let's try to be generic
        and not confuse people with system specific issues that change
        from one year to another.

        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 18:23:17 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16582
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 18:23:16 -0500 (EST)
Received: from standards (47.234.32.16:1461) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB240@standards.nortelnetworks.com>; Mon, 27 Nov 2000 16:04:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 136968 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 16:04:42
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:41988) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBB23E@standards.nortelnetworks.com>; Mon, 27 Nov 2000
          16:04:41 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id IAA22597 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 28 Nov 2000 08:18:24
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id IAA23275 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 28 Nov 2000 08:21:16
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD5QS2>; Tue, 28 Nov 2000 08:21:34 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613E8F@eaubrnt018.epa.ericsson.se>
Date:         Tue, 28 Nov 2000 08:21:31 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
              hes
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

        Hello Ajoy,

>         at source or target. Whereas I think, the fast handoff assumes
> that
>         it is possible to register mobile node through old access point
>         which is not possible in most of the current networks. For
> example,
>         in case of 802.11 network, it is not possible to register through
> the
>         old access point as only target AP knows about the handoff before
>         link layer handoff is complete. So we can not assume something
> which is not
>         doable in present network.  <AS>
>
        =>  Are you saying that the MN does not know that it's about to
        do a handoff in 802.11 ? If that's what you're saying then I
disagree.
        The MN would know that handoff is about to take place.
        Also please elaborate on why you say Fast Handoffs doesn't
        work in current systems. What is not doable in a present network ?

        While we're discussing this particular system (802.11) perhaps
        you could explain how the proactive approach would work in 802.11.
        A simple point form will do.

        Regards,
        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 18:23:17 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16591
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 18:23:17 -0500 (EST)
Received: from standards (47.234.32.16:1461) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB287@standards.nortelnetworks.com>; Mon, 27 Nov 2000 16:12:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 137064 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 16:12:16
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBB285@standards.nortelnetworks.com>;
          Mon, 27 Nov 2000 16:12:11 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id OAA27726 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 27 Nov 2000 14:29:23
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          NAA23272; Mon, 27 Nov 2000 13:29:22 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id NAA28237; Mon, 27 Nov 2000 13:29:10
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Pat Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.975360374.12237.pcalhoun@nasnfs>
Date:         Mon, 27 Nov 2000 13:26:14 -0800
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
              hes
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <4B6BC00CD15FD2119E5F0008C7A419A50C613E8A@eaubrnt018.epa.ericsson.se>

[I somehow missed this thread.... trying to catch up]


>         => You certainly addressed lots of issues. My point was concise
>         and straight forward. The proactive approach assumes a certain
>         architecture that allows the FA to know that the MN is about to
>         move. The handoff control is done completely by the network.
correct.

>         In some (or many) cases that is not the case. On the other hand
>         Fast Handoffs does not assume that, and it allows MN initiation
>         or Network initiation. This is simply due to the fact that it
> follows RFC2002,
>         which was designed in a very generic way, for a good reason.

Well, RFC 2002 is *the* way for mobile initiated handoff. If there is NO
network assistance, which is an assumption I'm making since you are stating
that the network does not know when the mobile is doing to handoff, then I see
no advantage in adding more to the protocol.

>
>         I gave WLAN as an example. There are more.
>         But there is no need to get into these system specific details.
>         As I'm sure you're aware, this is the MIP WG and not MIP for
>         cdma2000 or WLAN or something else. So let's try to be generic
>         and not confuse people with system specific issues that change
>         from one year to another.

hmmm..... how about you provide us with a concrete example? I know that Mobile
IP *will* be used for CDMA and WLAN. Now, if you have another link layer that
we should consider (because it will use Mobile IP), and we can provide that a
particular scheme does not work, then please let us know. However, I think
that we should be careful with your statement regarding system specific
issues. I think that we should solve problems that will be used. I am not sure
that solving problems that do not need to be solved is worth our while.

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 18:23:18 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16602
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 18:23:17 -0500 (EST)
Received: from standards (47.234.32.16:1461) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB2D7@standards.nortelnetworks.com>; Mon, 27 Nov 2000 16:29:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 137174 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 16:29:49
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:42428) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBB2D5@standards.nortelnetworks.com>; Mon, 27 Nov 2000
          16:29:48 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id IAA23964 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 28 Nov 2000 08:43:30
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id IAA25884 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 28 Nov 2000 08:46:23
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD5RHQ>; Tue, 28 Nov 2000 08:46:40 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613E91@eaubrnt018.epa.ericsson.se>
Date:         Tue, 28 Nov 2000 08:46:38 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
              hes
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> >         => You certainly addressed lots of issues. My point was concise
> >         and straight forward. The proactive approach assumes a certain
> >         architecture that allows the FA to know that the MN is about to
> >         move. The handoff control is done completely by the network.
> correct.
>
> >         In some (or many) cases that is not the case. On the other hand
> >         Fast Handoffs does not assume that, and it allows MN initiation
> >         or Network initiation. This is simply due to the fact that it
> > follows RFC2002,
> >         which was designed in a very generic way, for a good reason.
>
> Well, RFC 2002 is *the* way for mobile initiated handoff. If there is NO
> network assistance, which is an assumption I'm making since you are
> stating
> that the network does not know when the mobile is doing to handoff, then I
> see
> no advantage in adding more to the protocol.
>
        => We're not adding anything to the protocol, we're simply
        allowin for anticipation, bicasting is already in the basic
        protocol. We also argue that this basic protocol is all
        that is needed, provided anticipation is used. There is no
        need for having new messages and inter-FA security
        assumptions.

> >
> >         I gave WLAN as an example. There are more.
> >         But there is no need to get into these system specific details.
> >         As I'm sure you're aware, this is the MIP WG and not MIP for
> >         cdma2000 or WLAN or something else. So let's try to be generic
> >         and not confuse people with system specific issues that change
> >         from one year to another.
>
> hmmm..... how about you provide us with a concrete example? I know that
> Mobile
> IP *will* be used for CDMA and WLAN.
>
        => Correction, CDMA is a radio technology and not a system.
        As I said earlier there is no point in discussing these system
        specific details but to answer your question I already gave a very
        simple and concrete example, WLAN. The FA in a WLAN
        doesn't know the MN is about to move, so how would proactive
        address this issue.

        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 18:23:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16633
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 18:23:19 -0500 (EST)
Received: from standards (47.234.32.16:1107) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB338@standards.nortelnetworks.com>; Mon, 27 Nov 2000 17:30:10 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 137307 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 17:30:09
          -0500
Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBB336@standards.nortelnetworks.com>; Mon, 27 Nov 2000 17:30:09
          -0500
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA02227 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 27 Nov 2000 15:47:20
          -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100])
          by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA09387 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 27 Nov 2000 15:44:36
          -0700 (MST)]
Received: from ripcord756 (d50-497f.cig.mot.com [160.47.73.127]) by
          il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2651.58) id WQNKSGXL; Mon, 27 Nov 2000 16:47:16
          -0600
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.00.2314.1300
Approved-By:  Ajoy Singh <asingh1@EMAIL.MOT.COM>
Message-ID:  <NEBBIAJKMGAFBLOHKLJKGEEACBAA.asingh1@email.mot.com>
Date:         Mon, 27 Nov 2000 16:56:55 -0600
Reply-To: Ajoy Singh <asingh1@email.mot.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ajoy Singh <asingh1@email.mot.com>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approach
              hes
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4B6BC00CD15FD2119E5F0008C7A419A50C613E8F@eaubrnt018.epa.ericsson.se>
Content-Transfer-Encoding: 7bit

 =>  Are you saying that the MN does not know that it's about to
        do a handoff in 802.11 ? If that's what you're saying then I
disagree.

<AS> No, I was not saying that MN does not know about the link layer handoff
in
802.11. I was just saying that the source AP does not know about the
link layer handoff until link layer handoff is complete.
The MN does not have enough time to discover the IP address of
target FA through old AP and perform mobile/IP registration
through old AP with target FA. <AS>


        The MN would know that handoff is about to take place.
        Also please elaborate on why you say Fast Handoffs doesn't
        work in current systems. What is not doable in a present network ?

        While we're discussing this particular system (802.11) perhaps
        you could explain how the proactive approach would work in 802.11.
        A simple point form will do.

<AS> I think, 802.11 AP can be modified to provide target trigger
required for proactive handoff. Perhaps the target trigger can be initiated
at the reception of some link layer handoff message at target AP. The link
layer
message can be modified or some field of link layer message (e.g., source AP
id) can be used
to deduce the IP address of source FA required at target FA. Please
note we are not assuming that MN should be connected long enough
with source AP to allow sufficient time to perform mobile/IP registration
through old AP. This type of assumption brings lots of RF related
issues which may be too much to change and may adversely affect the
capacity of wireless network.  <AS>





-----Original Message-----
From: IP Routing for Wireless/Mobile Hosts (mobile-ip)
[mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Hesham
Soliman (EPA)
Sent: Monday, November 27, 2000 3:22 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff
approac hes


        Hello Ajoy,

>         at source or target. Whereas I think, the fast handoff assumes
> that
>         it is possible to register mobile node through old access point
>         which is not possible in most of the current networks. For
> example,
>         in case of 802.11 network, it is not possible to register through
> the
>         old access point as only target AP knows about the handoff before
>         link layer handoff is complete. So we can not assume something
> which is not
>         doable in present network.  <AS>
>
        =>  Are you saying that the MN does not know that it's about to
        do a handoff in 802.11 ? If that's what you're saying then I
disagree.
        The MN would know that handoff is about to take place.
        Also please elaborate on why you say Fast Handoffs doesn't
        work in current systems. What is not doable in a present network ?

        While we're discussing this particular system (802.11) perhaps
        you could explain how the proactive approach would work in 802.11.
        A simple point form will do.

        Regards,
        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 18:27:29 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17980
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 18:27:29 -0500 (EST)
Received: from standards (47.234.32.16:1156) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB3A4@standards.nortelnetworks.com>; Mon, 27 Nov 2000 18:08:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 137451 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 18:08:28
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:45421) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBB3A2@standards.nortelnetworks.com>; Mon, 27 Nov 2000
          18:08:27 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id KAA03446 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 28 Nov 2000 10:22:10
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id KAA10792 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 28 Nov 2000 10:25:01
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD5VK1>; Tue, 28 Nov 2000 10:25:18 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613E93@eaubrnt018.epa.ericsson.se>
Date:         Tue, 28 Nov 2000 10:25:08 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
              h
              hes
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>  =>  Are you saying that the MN does not know that it's about to
>         do a handoff in 802.11 ? If that's what you're saying then I
> disagree.
>
> <AS> No, I was not saying that MN does not know about the link layer
> handoff
> in
> 802.11.
>
        => Thank you that's my point.

>  I was just saying that the source AP does not know about the
> link layer handoff until link layer handoff is complete.
>
        => We're not discussing APs in MIP. We're talking about
        FAs. The AP doesn't know anything about MIP and it should remain
        tha way.

> The MN does not have enough time to discover the IP address of
> target FA through old AP and perform mobile/IP registration
> through old AP with target FA. <AS>
>
        => That's a speculative comment. I doubt that you can actually
        prove that.



>         The MN would know that handoff is about to take place.
>         Also please elaborate on why you say Fast Handoffs doesn't
>         work in current systems. What is not doable in a present network ?
>
>         While we're discussing this particular system (802.11) perhaps
>         you could explain how the proactive approach would work in 802.11.
>         A simple point form will do.
>
> <AS> I think, 802.11 AP can be modified to provide target trigger
> required for proactive handoff. Perhaps the target trigger can be
> initiated
> at the reception of some link layer handoff message at target AP. The link
> layer
>
        => So for proactive to work we have to modify that link layer.
        Exactly my point.


        Regards,
        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 18:47:14 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22581
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 18:47:14 -0500 (EST)
Received: from standards (47.234.32.16:1156) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB3EC@standards.nortelnetworks.com>; Mon, 27 Nov 2000 18:28:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 137549 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 18:28:11
          -0500
Received: from mailbreak.com (216.207.225.170:3027) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBB3EA@standards.nortelnetworks.com>; Mon, 27 Nov 2000
          18:28:11 -0500
Received: from SOLID [166.84.159.26] by mailbreak.com [216.207.225.174] with
          SMTP (MDaemon.v3.5.0.R) for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Mon, 27 Nov 2000 18:38:25 -0500
References:  <NEBBIAJKMGAFBLOHKLJKGEEACBAA.asingh1@email.mot.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-MDRemoteIP: 166.84.159.26
X-Return-Path: eunsoo@ctr.columbia.edu
X-MDaemon-Deliver-To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Approved-By:  Eunsoo Shim <eunsoo@CTR.COLUMBIA.EDU>
Message-ID:  <019101c058cc$b0bb4710$6401a8c0@SOLID>
Date:         Mon, 27 Nov 2000 18:49:32 -0500
Reply-To: Eunsoo Shim <eunsoo@ctr.columbia.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Eunsoo Shim <eunsoo@ctr.columbia.edu>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approach
              hes
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Please let me participate in this discussion.
Proactive Handoff requires modifications in link layer messages or system
functionality to convey the IP address of the new FA to the old FA or the
other way around as described in the below.
You might have good solutions to do it for CDMA networks and WLAN.
But I am hearing that people are trying to allow multiple access in
Bluetooth and also hearing about developments of various new wireless link
technologies. People would need to consider Proactive Handoff in their
wireless link design or system design to support fast handoff for IP.
I don't feel comfortable in putting some constraint on link layer
technologies to support mobility support in IP level.
IP is considered to be easy to deploy. I guess one of the reasons is that it
works with almost all the link layer technologies well without reqiring
modifications on lower layers.

Eunsoo

----- Original Message -----
From: "Ajoy Singh" <asingh1@email.mot.com>
To: <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Sent: Monday, November 27, 2000 5:56 PM
Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approach
hes


> =>  Are you saying that the MN does not know that it's about to
>         do a handoff in 802.11 ? If that's what you're saying then I
> disagree.
>
> <AS> No, I was not saying that MN does not know about the link layer
handoff
> in
> 802.11. I was just saying that the source AP does not know about the
> link layer handoff until link layer handoff is complete.
> The MN does not have enough time to discover the IP address of
> target FA through old AP and perform mobile/IP registration
> through old AP with target FA. <AS>
>
>
>         The MN would know that handoff is about to take place.
>         Also please elaborate on why you say Fast Handoffs doesn't
>         work in current systems. What is not doable in a present network ?
>
>         While we're discussing this particular system (802.11) perhaps
>         you could explain how the proactive approach would work in 802.11.
>         A simple point form will do.
>
> <AS> I think, 802.11 AP can be modified to provide target trigger
> required for proactive handoff. Perhaps the target trigger can be
initiated
> at the reception of some link layer handoff message at target AP. The link
> layer
> message can be modified or some field of link layer message (e.g., source
AP
> id) can be used
> to deduce the IP address of source FA required at target FA. Please
> note we are not assuming that MN should be connected long enough
> with source AP to allow sufficient time to perform mobile/IP registration
> through old AP. This type of assumption brings lots of RF related
> issues which may be too much to change and may adversely affect the
> capacity of wireless network.  <AS>
>
>
>
>
>
> -----Original Message-----
> From: IP Routing for Wireless/Mobile Hosts (mobile-ip)
> [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Hesham
> Soliman (EPA)
> Sent: Monday, November 27, 2000 3:22 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff
> approac hes
>
>
>         Hello Ajoy,
>
> >         at source or target. Whereas I think, the fast handoff assumes
> > that
> >         it is possible to register mobile node through old access point
> >         which is not possible in most of the current networks. For
> > example,
> >         in case of 802.11 network, it is not possible to register
through
> > the
> >         old access point as only target AP knows about the handoff
before
> >         link layer handoff is complete. So we can not assume something
> > which is not
> >         doable in present network.  <AS>
> >
>         =>  Are you saying that the MN does not know that it's about to
>         do a handoff in 802.11 ? If that's what you're saying then I
> disagree.
>         The MN would know that handoff is about to take place.
>         Also please elaborate on why you say Fast Handoffs doesn't
>         work in current systems. What is not doable in a present network ?
>
>         While we're discussing this particular system (802.11) perhaps
>         you could explain how the proactive approach would work in 802.11.
>         A simple point form will do.
>
>         Regards,
>         Hesham
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 18:58:00 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25065
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 18:57:59 -0500 (EST)
Received: from standards (47.234.32.16:1156) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB434@standards.nortelnetworks.com>; Mon, 27 Nov 2000 18:38:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 137648 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 18:38:47
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBB432@standards.nortelnetworks.com>;
          Mon, 27 Nov 2000 18:38:47 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id QAA05572; Mon, 27 Nov 2000 16:55:57
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          PAA03715; Mon, 27 Nov 2000 15:55:56 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id PAA02207; Mon, 27 Nov 2000 15:55:49
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Pat Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.975369174.23030.pcalhoun@nasnfs>
Date:         Mon, 27 Nov 2000 15:52:54 -0800
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approach
              hes
X-To:         Eunsoo Shim <eunsoo@ctr.columbia.edu>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" <019101c058cc$b0bb4710$6401a8c0@SOLID>

> Proactive Handoff requires modifications in link layer messages or system
> functionality to convey the IP address of the new FA to the old FA or the
> other way around as described in the below.

Not at all. I am not sure where this came from.

> You might have good solutions to do it for CDMA networks and WLAN.
> But I am hearing that people are trying to allow multiple access in
> Bluetooth and also hearing about developments of various new wireless link
> technologies.
Exactly what we intended

> People would need to consider Proactive Handoff in their
> wireless link design or system design to support fast handoff for IP.
> I don't feel comfortable in putting some constraint on link layer
> technologies to support mobility support in IP level.
> IP is considered to be easy to deploy. I guess one of the reasons is that it
> works with almost all the link layer technologies well without reqiring
> modifications on lower layers.

Right, and I would feel uncomfortable with requiring mods to link layers as
well.

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 19:04:22 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26468
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 19:04:22 -0500 (EST)
Received: from standards (47.234.32.16:1156) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB474@standards.nortelnetworks.com>; Mon, 27 Nov 2000 18:45:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 137737 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 18:45:13
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBB472@standards.nortelnetworks.com>;
          Mon, 27 Nov 2000 18:45:12 -0500
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id RAA09563 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 27 Nov 2000 17:02:24
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          QAA09397; Mon, 27 Nov 2000 16:02:23 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id QAA02355; Mon, 27 Nov 2000 16:02:20
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Pat Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.975369565.30971.pcalhoun@nasnfs>
Date:         Mon, 27 Nov 2000 15:59:25 -0800
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
              hes
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <4B6BC00CD15FD2119E5F0008C7A419A50C613E91@eaubrnt018.epa.ericsson.se>

> > >         => You certainly addressed lots of issues. My point was concise
> > >         and straight forward. The proactive approach assumes a certain
> > >         architecture that allows the FA to know that the MN is about to
> > >         move. The handoff control is done completely by the network.
> > correct.
> >
> > >         In some (or many) cases that is not the case. On the other hand
> > >         Fast Handoffs does not assume that, and it allows MN initiation
> > >         or Network initiation. This is simply due to the fact that it
> > > follows RFC2002,
> > >         which was designed in a very generic way, for a good reason.
> >
> > Well, RFC 2002 is *the* way for mobile initiated handoff. If there is NO
> > network assistance, which is an assumption I'm making since you are
> > stating
> > that the network does not know when the mobile is doing to handoff, then I
> > see
> > no advantage in adding more to the protocol.
> >
>         => We're not adding anything to the protocol, we're simply
>         allowin for anticipation, bicasting is already in the basic
>         protocol. We also argue that this basic protocol is all
>         that is needed, provided anticipation is used. There is no
>         need for having new messages and inter-FA security
>         assumptions.

I don't see new messages as really being an issue here, and if you are to have
FAs talk to each other, then it better be secured.

>
> > >
> > >         I gave WLAN as an example. There are more.
> > >         But there is no need to get into these system specific details.
> > >         As I'm sure you're aware, this is the MIP WG and not MIP for
> > >         cdma2000 or WLAN or something else. So let's try to be generic
> > >         and not confuse people with system specific issues that change
> > >         from one year to another.
> >
> > hmmm..... how about you provide us with a concrete example? I know that
> > Mobile
> > IP *will* be used for CDMA and WLAN.
> >
>         => Correction, CDMA is a radio technology and not a system.
>         As I said earlier there is no point in discussing these system
>         specific details but to answer your question I already gave a very
>         simple and concrete example, WLAN. The FA in a WLAN
>         doesn't know the MN is about to move, so how would proactive
>         address this issue.

sorry, but I don't buy this one. The fact that *some* existing WLAN APs are
not systems is really an implementation issue. Cisco's 802.11 AP includes
Mobile IP Foreign Agent functionality. No link layer changes are required.

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 19:23:12 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00602
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 19:23:11 -0500 (EST)
Received: from standards (47.234.32.16:1156) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB4CD@standards.nortelnetworks.com>; Mon, 27 Nov 2000 19:04:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 137860 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 19:04:12
          -0500
Received: from mailbreak.com (216.207.225.170:3130) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBB4CB@standards.nortelnetworks.com>; Mon, 27 Nov 2000
          19:04:12 -0500
Received: from SOLID [166.84.159.26] by mailbreak.com [216.207.225.174] with
          SMTP (MDaemon.v3.5.0.R) for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Mon, 27 Nov 2000 19:13:18 -0500
References:  <Roam.SIMC.2.0.6.975369174.23030.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-MDRemoteIP: 166.84.159.26
X-Return-Path: eunsoo@ctr.columbia.edu
X-MDaemon-Deliver-To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Approved-By:  Eunsoo Shim <eunsoo@CTR.COLUMBIA.EDU>
Message-ID:  <020401c058d1$8fdcdf40$6401a8c0@SOLID>
Date:         Mon, 27 Nov 2000 19:24:03 -0500
Reply-To: Eunsoo Shim <eunsoo@ctr.columbia.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Eunsoo Shim <eunsoo@ctr.columbia.edu>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approach
              hes
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: "Pat Calhoun" <Pat.Calhoun@Eng.Sun.COM>
To: <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Sent: Monday, November 27, 2000 6:52 PM
Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approach
hes


> > Proactive Handoff requires modifications in link layer messages or
system
> > functionality to convey the IP address of the new FA to the old FA or
the
> > other way around as described in the below.
>
> Not at all. I am not sure where this came from.
>

That came from a few things.
One of them is one of Ajoy's messages copied in the below. To stress the
point, I copied it from Hesham's reply to Ajoy's message.
Also I don't know how the IP address of the new FA can be conveyed to the
old FA in the existing wireless networks without any modification in the
link layer messages or the network system and I have not heard any explicit
answer about it after I asked the question in this mailing list.
If you let me know it, I would appreicate it.
----------------------
> <AS> I think, 802.11 AP can be modified to provide target trigger
> required for proactive handoff. Perhaps the target trigger can be
> initiated
> at the reception of some link layer handoff message at target AP. The link
> layer
>
        => So for proactive to work we have to modify that link layer.
        Exactly my point.


        Regards,
        Hesham
-----------------------


> > You might have good solutions to do it for CDMA networks and WLAN.
> > But I am hearing that people are trying to allow multiple access in
> > Bluetooth and also hearing about developments of various new wireless
link
> > technologies.
> Exactly what we intended
>
> > People would need to consider Proactive Handoff in their
> > wireless link design or system design to support fast handoff for IP.
> > I don't feel comfortable in putting some constraint on link layer
> > technologies to support mobility support in IP level.
> > IP is considered to be easy to deploy. I guess one of the reasons is
that it
> > works with almost all the link layer technologies well without reqiring
> > modifications on lower layers.
>
> Right, and I would feel uncomfortable with requiring mods to link layers
as
> well.
>
> PatC
>

I am glad that we are in the same position regarding it. I don't like
arguing about philosophical differences. :-)
Then please let me state my question again:
How would the new FA know the IP address of the old FA?

This is my biggest and probably sole question about Proactive Handoff.
Thanks.

Eunsoo


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 19:34:51 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03193
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 19:34:50 -0500 (EST)
Received: from standards (47.234.32.16:1156) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB50E@standards.nortelnetworks.com>; Mon, 27 Nov 2000 19:15:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 137949 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 19:15:52
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBB50C@standards.nortelnetworks.com>;
          Mon, 27 Nov 2000 19:15:51 -0500
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id RAA29580; Mon, 27 Nov 2000 17:33:02
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          QAA18433; Mon, 27 Nov 2000 16:33:02 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id QAA03034; Mon, 27 Nov 2000 16:33:00
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Pat Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.975371404.30724.pcalhoun@nasnfs>
Date:         Mon, 27 Nov 2000 16:30:04 -0800
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approach
              hes
X-To:         Eunsoo Shim <eunsoo@ctr.columbia.edu>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" <020401c058d1$8fdcdf40$6401a8c0@SOLID>

[...]
>
> I am glad that we are in the same position regarding it. I don't like
> arguing about philosophical differences. :-)

Good, because that's pretty much where this whole thing has ended up...
somewhat reminds me of the current elections :)

> Then please let me state my question again:
> How would the new FA know the IP address of the old FA?

How a Foreign Agent knows the identity of Access Points, Base Stations, or
whatever terminology one wants to use is through configuration. When a network
is deployed, each adjoining cells (or coverate area) are configured, as are
the IP addresses of the Foreign Agents handling those cells.

btw, there is NO difference here between proactive and fast handoff. In both
cases, the old Foreign Agent contacts the new Foreign Agent. This is either
via the Handoff-Request (Proactive), or by issuing an Agent Advertisement on
behalf of the Mobile Node. If one wants to have smooth handoffs (I am using
the term smooth here because fast handoff would incorrectly reference Hesham's
proposal).


>
> This is my biggest and probably sole question about Proactive Handoff.

I hope I answered it.

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 19:44:09 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05213
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 19:44:08 -0500 (EST)
Received: from standards (47.234.32.16:1156) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB555@standards.nortelnetworks.com>; Mon, 27 Nov 2000 19:25:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 138047 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 19:25:14
          -0500
Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBB553@standards.nortelnetworks.com>; Mon, 27 Nov 2000 19:25:13
          -0500
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          motgate2.mot.com (motgate2 2.1) with ESMTP id RAA01923 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 27 Nov 2000 17:42:11
          -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100])
          by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id RAA03119 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 27 Nov 2000 17:42:10
          -0700 (MST)]
Received: from ripcord756 (d50-497f.cig.mot.com [160.47.73.127]) by
          il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2651.58) id WQNKSJT1; Mon, 27 Nov 2000 18:42:07
          -0600
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.00.2314.1300
Approved-By:  Ajoy Singh <asingh1@EMAIL.MOT.COM>
Message-ID:  <NEBBIAJKMGAFBLOHKLJKIEEBCBAA.asingh1@email.mot.com>
Date:         Mon, 27 Nov 2000 18:51:47 -0600
Reply-To: Ajoy Singh <asingh1@email.mot.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ajoy Singh <asingh1@email.mot.com>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approach
              hes
X-To:         Eunsoo Shim <eunsoo@ctr.columbia.edu>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <020401c058d1$8fdcdf40$6401a8c0@SOLID>
Content-Transfer-Encoding: 7bit

That came from a few things.
One of them is one of Ajoy's messages copied in the below. To stress the
point, I copied it from Hesham's reply to Ajoy's message.

<AS> If AP implements FA functionality then no link layer change is
required to support Proactive handoff. The link layer message carries source
AP ID which can be used
to deduce source FA address.  I think, Pat mentioned that Cisco
AP supports FA functionality. <AS>

-----Original Message-----
From: IP Routing for Wireless/Mobile Hosts (mobile-ip)
[mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Eunsoo Shim
Sent: Monday, November 27, 2000 6:24 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff
approach hes


----- Original Message -----
From: "Pat Calhoun" <Pat.Calhoun@Eng.Sun.COM>
To: <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Sent: Monday, November 27, 2000 6:52 PM
Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approach
hes


> > Proactive Handoff requires modifications in link layer messages or
system
> > functionality to convey the IP address of the new FA to the old FA or
the
> > other way around as described in the below.
>
> Not at all. I am not sure where this came from.
>

That came from a few things.
One of them is one of Ajoy's messages copied in the below. To stress the
point, I copied it from Hesham's reply to Ajoy's message.
Also I don't know how the IP address of the new FA can be conveyed to the
old FA in the existing wireless networks without any modification in the
link layer messages or the network system and I have not heard any explicit
answer about it after I asked the question in this mailing list.
If you let me know it, I would appreicate it.
----------------------
> <AS> I think, 802.11 AP can be modified to provide target trigger
> required for proactive handoff. Perhaps the target trigger can be
> initiated
> at the reception of some link layer handoff message at target AP. The link
> layer
>
        => So for proactive to work we have to modify that link layer.
        Exactly my point.


        Regards,
        Hesham
-----------------------


> > You might have good solutions to do it for CDMA networks and WLAN.
> > But I am hearing that people are trying to allow multiple access in
> > Bluetooth and also hearing about developments of various new wireless
link
> > technologies.
> Exactly what we intended
>
> > People would need to consider Proactive Handoff in their
> > wireless link design or system design to support fast handoff for IP.
> > I don't feel comfortable in putting some constraint on link layer
> > technologies to support mobility support in IP level.
> > IP is considered to be easy to deploy. I guess one of the reasons is
that it
> > works with almost all the link layer technologies well without reqiring
> > modifications on lower layers.
>
> Right, and I would feel uncomfortable with requiring mods to link layers
as
> well.
>
> PatC
>

I am glad that we are in the same position regarding it. I don't like
arguing about philosophical differences. :-)
Then please let me state my question again:
How would the new FA know the IP address of the old FA?

This is my biggest and probably sole question about Proactive Handoff.
Thanks.

Eunsoo


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 21:15:39 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25895
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 21:15:38 -0500 (EST)
Received: from standards (47.234.32.16:4980) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB5F9@standards.nortelnetworks.com>; Mon, 27 Nov 2000 20:56:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 138262 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 20:56:31
          -0500
Received: from mailbreak.com (216.207.225.170:3473) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBB5F7@standards.nortelnetworks.com>; Mon, 27 Nov 2000
          20:56:31 -0500
Received: from SOLID [166.84.159.26] by mailbreak.com [216.207.225.174] with
          SMTP (MDaemon.v3.5.0.R) for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Mon, 27 Nov 2000 21:06:24 -0500
References:  <NEBBIAJKMGAFBLOHKLJKIEEBCBAA.asingh1@email.mot.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-MDRemoteIP: 166.84.159.26
X-Return-Path: eunsoo@ctr.columbia.edu
X-MDaemon-Deliver-To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Approved-By:  Eunsoo Shim <eunsoo@CTR.COLUMBIA.EDU>
Message-ID:  <02ba01c058e1$5cafb9c0$6401a8c0@SOLID>
Date:         Mon, 27 Nov 2000 21:17:30 -0500
Reply-To: Eunsoo Shim <eunsoo@ctr.columbia.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Eunsoo Shim <eunsoo@ctr.columbia.edu>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approach
              hes
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: "Ajoy Singh" <asingh1@email.mot.com>
To: <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Sent: Monday, November 27, 2000 7:51 PM
Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approach
hes


> That came from a few things.
> One of them is one of Ajoy's messages copied in the below. To stress the
> point, I copied it from Hesham's reply to Ajoy's message.
>
> <AS> If AP implements FA functionality then no link layer change is
> required to support Proactive handoff. The link layer message carries
source
> AP ID which can be used
> to deduce source FA address.  I think, Pat mentioned that Cisco
> AP supports FA functionality. <AS>
>

[eunsoo]
In CDMA's soft handoff mechanisms, the MN provides id of the new BS in the
link layer message to the old BS.
So if the FA has access all the contents of the link layer messages to the
BS or they are the same entity as you said in the above, the FA would be
able to figure out IP address of the new FA or the old FA from configuration
or other similar mechanisms.
Recently I saw slides showing the all IP approaches in the 3GPP2, which put
BCS and PCF between BS and PDSN. It seems to me they want to put FA at PDSN.
I don't know all the details of the interfaces between each entity and what
information is transferred between them. But it does not look obvious that
the FA has access to all the information each BS gets. Actually you said
there might be need for 'slight' modification in a previous email. I copied
that part from your email in the below.
------------------------
<copied from one of Ajoy's messages>
> -> Even in case of CDMA network, FA is not collocated with radio quipment.
> We all agree that some changes are required at network side to
> get trigger at source/target Foreign agent. For example, in case of CDMA
> 2000, we might
> have to make slight modification to R-P interface to send foreign agent
> address
> from PCF to PDSN. Similarly, we have to make some changes where FA is not
> collocated
> with radio equipment. The exact nature of changes will be dependent upon
> the
> specific technology and should be decided by respective SDOs.
------------------------

If 3GPP2 people put FA on BS, this would disappear again I guess.
Probably it can be argued that this is a matter of network configuration or
implementation.
I wonder whether it is a simple issue for them to change the location of the
FA from the PDSN to the BS.
I hope it is.
Still I have some questions.
How about 3GPP?
I think CDMA will be a dominent wireless link technologies in the near
future since all 3G technologies are based on CDMA and also WLAN is. Due to
its soft handoff capability, the new BS's ID and other similar information
can be retrieved from the old BS.
Can we assume this kind of soft handoff is generally available in the
current or future wireless technologies? Isn't it a special case considering
many kinds of wireless network technologies? Also such capability is not
available with GSM. People say 2G network won't disappear very soon. Do we
exclude GSM or other non-CDMA wireless networks from our handoff design?

I am not sure whether supporting WCDMA, CDMA2000 and WLAN (802.11 probably)
is good enough. Am I bringing in non-practical concerns?

Thanks.

Eunsoo

> -----Original Message-----
> From: IP Routing for Wireless/Mobile Hosts (mobile-ip)
> [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Eunsoo Shim
> Sent: Monday, November 27, 2000 6:24 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff
> approach hes
>
>
> ----- Original Message -----
> From: "Pat Calhoun" <Pat.Calhoun@Eng.Sun.COM>
> To: <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
> Sent: Monday, November 27, 2000 6:52 PM
> Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff
approach
> hes
>
>
> > > Proactive Handoff requires modifications in link layer messages or
> system
> > > functionality to convey the IP address of the new FA to the old FA or
> the
> > > other way around as described in the below.
> >
> > Not at all. I am not sure where this came from.
> >
>
> That came from a few things.
> One of them is one of Ajoy's messages copied in the below. To stress the
> point, I copied it from Hesham's reply to Ajoy's message.
> Also I don't know how the IP address of the new FA can be conveyed to the
> old FA in the existing wireless networks without any modification in the
> link layer messages or the network system and I have not heard any
explicit
> answer about it after I asked the question in this mailing list.
> If you let me know it, I would appreicate it.
> ----------------------
> > <AS> I think, 802.11 AP can be modified to provide target trigger
> > required for proactive handoff. Perhaps the target trigger can be
> > initiated
> > at the reception of some link layer handoff message at target AP. The
link
> > layer
> >
>         => So for proactive to work we have to modify that link layer.
>         Exactly my point.
>
>
>         Regards,
>         Hesham
> -----------------------
>
>
> > > You might have good solutions to do it for CDMA networks and WLAN.
> > > But I am hearing that people are trying to allow multiple access in
> > > Bluetooth and also hearing about developments of various new wireless
> link
> > > technologies.
> > Exactly what we intended
> >
> > > People would need to consider Proactive Handoff in their
> > > wireless link design or system design to support fast handoff for IP.
> > > I don't feel comfortable in putting some constraint on link layer
> > > technologies to support mobility support in IP level.
> > > IP is considered to be easy to deploy. I guess one of the reasons is
> that it
> > > works with almost all the link layer technologies well without
reqiring
> > > modifications on lower layers.
> >
> > Right, and I would feel uncomfortable with requiring mods to link layers
> as
> > well.
> >
> > PatC
> >
>
> I am glad that we are in the same position regarding it. I don't like
> arguing about philosophical differences. :-)
> Then please let me state my question again:
> How would the new FA know the IP address of the old FA?
>
> This is my biggest and probably sole question about Proactive Handoff.
> Thanks.
>
> Eunsoo
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Nov 27 21:23:09 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27608
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Nov 2000 21:23:09 -0500 (EST)
Received: from standards (47.234.32.16:4980) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB636@standards.nortelnetworks.com>; Mon, 27 Nov 2000 21:04:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 138348 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 21:04:05
          -0500
Received: from mailbreak.com (216.207.225.170:3495) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBB634@standards.nortelnetworks.com>; Mon, 27 Nov 2000
          21:04:05 -0500
Received: from SOLID [166.84.159.26] by mailbreak.com [216.207.225.174] with
          SMTP (MDaemon.v3.5.0.R) for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Mon, 27 Nov 2000 21:13:57 -0500
References:  <Roam.SIMC.2.0.6.975371404.30724.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-MDRemoteIP: 166.84.159.26
X-Return-Path: eunsoo@ctr.columbia.edu
X-MDaemon-Deliver-To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Approved-By:  Eunsoo Shim <eunsoo@CTR.COLUMBIA.EDU>
Message-ID:  <02bb01c058e2$6a242220$6401a8c0@SOLID>
Date:         Mon, 27 Nov 2000 21:25:01 -0500
Reply-To: Eunsoo Shim <eunsoo@ctr.columbia.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Eunsoo Shim <eunsoo@ctr.columbia.edu>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approach
              hes
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: "Pat Calhoun" <Pat.Calhoun@Eng.Sun.COM>
To: <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Sent: Monday, November 27, 2000 7:30 PM
Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approach
hes


> [...]
> >
> > I am glad that we are in the same position regarding it. I don't like
> > arguing about philosophical differences. :-)
>
> Good, because that's pretty much where this whole thing has ended up...
> somewhat reminds me of the current elections :)
>
> > Then please let me state my question again:
> > How would the new FA know the IP address of the old FA?
>
> How a Foreign Agent knows the identity of Access Points, Base Stations, or
> whatever terminology one wants to use is through configuration. When a
network
> is deployed, each adjoining cells (or coverate area) are configured, as
are
> the IP addresses of the Foreign Agents handling those cells.
>

[eunsoo]
Probably I did not state my question very well.
What you are saying is that mapping between cells (or AP or BS) and the
correspoding FA's addresses is configured.
I understand this.

My question is how the old FA finds out the IP address of the new FA before
the MN registers itself with the new FA?
1) First of all, it requires the old FA to know where the MN is going. Then
the old FA should be able to retreive the ID of the BS covering the new cell
or area.
2) Last, it should be able to map the information to the IP address of the
new FA.

Without assuming soft handoff in link layer, I wonder how the old FA knows
where the MN is going.
I guess you answered about the second issue, that is, 2) in the above.

Thanks.

Eunsoo


> btw, there is NO difference here between proactive and fast handoff. In
both
> cases, the old Foreign Agent contacts the new Foreign Agent. This is
either
> via the Handoff-Request (Proactive), or by issuing an Agent Advertisement
on
> behalf of the Mobile Node. If one wants to have smooth handoffs (I am
using
> the term smooth here because fast handoff would incorrectly reference
Hesham's
> proposal).
>
>
> >
> > This is my biggest and probably sole question about Proactive Handoff.
>
> I hope I answered it.
>
> PatC
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 02:20:59 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08602
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 02:20:58 -0500 (EST)
Received: from standards (47.234.32.16:2510) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB790@standards.nortelnetworks.com>; Tue, 28 Nov 2000 2:01:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 138782 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 02:01:06
          -0500
Received: from melanieb.vtt.fi by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBB78E@standards.nortelnetworks.com>; Tue, 28 Nov 2000 2:01:06
          -0500
Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi
          (8.9.3/8.9.3) with ESMTP id JAA19478 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 28 Nov 2000 09:18:19
          +0200 (EET)
Received: from tko103.vttele (tko103 [130.188.92.203]) by elemail.ele.vtt.fi
          (8.9.1a/8.9.1) with ESMTP id JAA26075 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 28 Nov 2000 09:18:18
          +0200 (EET)
X-Mailer: The Bat! (v1.46) UNREG / CD5BF9353B3B7091
X-Priority: 3 (Normal)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Approved-By:  Zach Shelby <zach.shelby@VTT.FI>
Message-ID:  <17753569735.20001128091540@vtt.fi>
Date:         Tue, 28 Nov 2000 09:15:40 +0200
Reply-To: Zach Shelby <zach.shelby@vtt.fi>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Zach Shelby <zach.shelby@vtt.fi>
Organization: VTT Electronics, Finland
Subject:      [MOBILE-IP] I-D submitted to Seamoby
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

This is to announce a draft to be discussed in the seamoby WG meeting,
we think many in the mobileip group would be interested to take a
look.

Title: Cellular IPv6
Link: http://www.ietf.org/internet-drafts/draft-shelby-seamoby-cellularipv6-00.txt
Summary:

The original Cellular IP protocol is upgraded, taking advantage of
IPv6 features and transparent integration with MIPv6. A new technique
for indirect handoffs is also added to this draft.

This is a custom announcement, somehow the official didn't get sent to
the mailing lists.

Regards,
Zach Shelby

----------------------------------------------------------------------
   Zach Shelby - Researcher         Zach.Shelby@vtt.fi
   VTT Elektronics                  Phone   +358 8 551 2164 (Office)
   Kaitoväylä 1, PL 1100            Fax     +358 8 551 2320
   90571 Oulu, Finland              Mobile  +358 40 7796297
----------------------------------------------------------------------
                    http://paula.oulu.fi/~zdshelby
       Home:   Yliopistokatu 14-707  90570 Oulu, Finland


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 06:21:05 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14431
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 06:21:05 -0500 (EST)
Received: from standards (47.234.32.16:3184) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB8C2@standards.nortelnetworks.com>; Tue, 28 Nov 2000 6:01:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 139199 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 06:01:45
          -0500
Received: from dv.op.dlr.de (n13.sp.op.dlr.de) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBB8C0@standards.nortelnetworks.com>; Tue, 28 Nov 2000 6:01:45
          -0500
Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) by
          dv.op.dlr.de (8.10.1/8.10.1) with ESMTP id eASBIwZ52076 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 28 Nov 2000 12:18:58
          +0100
Received: from zeus.nt.op.dlr.de (pcdn183_nt_op [129.247.173.183]) by
          zeus.nt.op.dlr.de (8.9.1b+Sun/8.9.1) with ESMTP id MAA02637 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 28 Nov 2000 12:18:57
          +0100 (MET)
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Matteo Berioli <berioli@ZEUS.NT.OP.DLR.DE>
Message-ID:  <3A23949F.97C84510@zeus.nt.op.dlr.de>
Date:         Tue, 28 Nov 2000 12:18:55 +0100
Reply-To: mberio@libero.it
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Matteo Berioli <berioli@zeus.nt.op.dlr.de>
Subject:      [MOBILE-IP] IPv6 user with Foreign Agent CoA!?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Let us assume that I am an IPv6 mobile host, and I usually decapsulate
datagrams
coming from my Home Agent by myself, since in IPv6 only
Co-located Care-of Addresses exist.

During my motion, I have to attach myself to a Mobile Router.
It has got only one Co-located Care-of Address and it
has to manage with it the whole mobile network that is behind it.
This is not a problem, since it can assign to all
the hosts of the mobile network, a Foreign Agent CoA, and in order to
correctly forward the packets, it can decapsulate the datagrams and
look at the home addresses in the inner headers.

But this time it cannot assign to me my own Co-located Care-of Address,
even if I am an IPv6 host and I would wish to acquire only Co-located
CoAes.
As a matter of fact all the hosts attached to this mobile router have
to share the only CoA assigned to it.
So the mobile router will decapsulate also the datagrams directed to me,

and it will forward them directly on the network, without encapsulation.

The question is:
Is that a problem, if I receive already decapsulated datagrams, even
if usually I decapsulate them by myself?!

Clarifications are welcome.

Thanks,
Matteo Berioli


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 07:26:29 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08382
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 07:26:28 -0500 (EST)
Received: from standards (47.234.32.16:3184) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB9BB@standards.nortelnetworks.com>; Tue, 28 Nov 2000 7:07:27 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 139498 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 07:07:27
          -0500
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBB9B9@standards.nortelnetworks.com>; Tue, 28 Nov 2000
          7:07:27 -0500
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 eASCOet02518 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 28 Nov 2000 13:24:40
          +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ;
          Tue Nov 28 13:24:39 2000 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service
          (5.5.2651.58) id <XXQTH2HA>; Tue, 28 Nov 2000 13:22:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Karim El-Malki (ERA)" <Karim.El-Malki@ERA.ERICSSON.SE>
Message-ID:  <5F05C89FB2F8D211B6430008C791912707460302@esealnt190>
Date:         Tue, 28 Nov 2000 13:24:36 +0100
Reply-To: "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
              h hes
X-To:         Eunsoo Shim <eunsoo@ctr.columbia.edu>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> I am not sure whether supporting WCDMA, CDMA2000 and WLAN
> (802.11 probably)
> is good enough. Am I bringing in non-practical concerns?
>

I agree that the method to speed up handoffs should be generic
to support multiple technologies and not only consider specific
systems. In fact this is one of the assumptions in the handoffs
work although there have been a number of technology/system specific
issues which have been brought up.

Regards
/Karim


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 09:06:17 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15652
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 09:06:16 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBA58@standards.nortelnetworks.com>; Tue, 28 Nov 2000 8:47:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 139704 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 08:47:04
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:62043) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBBA56@standards.nortelnetworks.com>; Tue, 28 Nov 2000
          8:47:03 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id BAA22916 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Nov 2000 01:00:48
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id BAA14404 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Nov 2000 01:03:40
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD63F9>; Wed, 29 Nov 2000 01:03:56 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613E9B@eaubrnt018.epa.ericsson.se>
Date:         Wed, 29 Nov 2000 01:03:55 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] IPv6 user with Foreign Agent CoA!?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> Let us assume that I am an IPv6 mobile host, and I usually decapsulate
> datagrams
> coming from my Home Agent by myself, since in IPv6 only
> Co-located Care-of Addresses exist.
>
> During my motion, I have to attach myself to a Mobile Router.
> It has got only one Co-located Care-of Address and it
> has to manage with it the whole mobile network that is behind it.
> This is not a problem, since it can assign to all
> the hosts of the mobile network, a Foreign Agent CoA, and in order to
> correctly forward the packets, it can decapsulate the datagrams and
> look at the home addresses in the inner headers.
>
> But this time it cannot assign to me my own Co-located Care-of Address,
> even if I am an IPv6 host and I would wish to acquire only Co-located
> CoAes.
> As a matter of fact all the hosts attached to this mobile router have
> to share the only CoA assigned to it.
> So the mobile router will decapsulate also the datagrams directed to me,
>
> and it will forward them directly on the network, without encapsulation.
>
> The question is:
> Is that a problem, if I receive already decapsulated datagrams, even
> if usually I decapsulate them by myself?!
>
> Clarifications are welcome.
>
        => Your scenario is supported in draft-ietf-mobileip-hmipv6-02
        which will be on the web very soon. I think you'll get the answer
        you're looking for there.
        But as a short answer, no there is no problem because the MN
        doesn't think that it moved since it is still sending and receiving
        packets using its Home address.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 09:38:06 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29755
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 09:38:06 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBAB9@standards.nortelnetworks.com>; Tue, 28 Nov 2000 9:18:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 139831 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 09:18:50
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:62256) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBBAB7@standards.nortelnetworks.com>; Tue, 28 Nov 2000
          9:18:49 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id BAA23462 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Nov 2000 01:32:33
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id BAA16668 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Nov 2000 01:35:25
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD63X6>; Wed, 29 Nov 2000 01:35:41 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613E9E@eaubrnt018.epa.ericsson.se>
Date:         Wed, 29 Nov 2000 01:35:41 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
              hes
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> >         => We're not adding anything to the protocol, we're simply
> >         allowin for anticipation, bicasting is already in the basic
> >         protocol. We also argue that this basic protocol is all
> >         that is needed, provided anticipation is used. There is no
> >         need for having new messages and inter-FA security
> >         assumptions.
>
> I don't see new messages as really being an issue here, and if you are to
> have
> FAs talk to each other, then it better be secured.
>
        => I do think it's an issue. It's important for deployment. The
        bigger issue is that they are not needed. I agree that if FA's
        talk to each other then the messages should be secured.
        But as far as MIP is concerned they don't need to talk to
        each other, so there is no need for that extra security
        requirement.

> > > hmmm..... how about you provide us with a concrete example? I know
> that
> > > Mobile
> > > IP *will* be used for CDMA and WLAN.
> > >
> >         => Correction, CDMA is a radio technology and not a system.
> >         As I said earlier there is no point in discussing these system
> >         specific details but to answer your question I already gave a
> very
> >         simple and concrete example, WLAN. The FA in a WLAN
> >         doesn't know the MN is about to move, so how would proactive
> >         address this issue.
>
> sorry, but I don't buy this one. The fact that *some* existing WLAN APs
> are
> not systems is really an implementation issue.
>
        => "some" ? The "majority" is a better word I think.
        I agree it is a configuration issue but it seems that
        this configuraton is very popular.

> Cisco's 802.11 AP includes
> Mobile IP Foreign Agent functionality. No link layer changes are required.
>
        => Ok ! So to be accurate we can say that in the case of WLAN
        the proactive approach will only work if the AP and the FA are
colocated.
        This is exactly what I'm trying to explain, the proactive approach
only
        works for certain architectures. This is a new limitation to MIP
that we
        didn't have before. So for the cases where the FA is not aware of
the
        L2 mobility (eg. most WLANs and 3GPP) , this approach doesn't work.
        In 3GPP the FA is not aware of the degradation in the radio link,
and does
        not get that L2 trigger. Therefore I don't think that this approach
will
        work their either.

        Regards,
        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 10:04:10 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11493
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 10:04:10 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBB1C@standards.nortelnetworks.com>; Tue, 28 Nov 2000 9:45:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 139958 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 09:45:00
          -0500
Received: from dv.op.dlr.de (n13.sp.op.dlr.de) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBBB1A@standards.nortelnetworks.com>; Tue, 28 Nov 2000 9:45:00
          -0500
Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) by
          dv.op.dlr.de (8.10.1/8.10.1) with ESMTP id eASF2DZ56832 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 28 Nov 2000 16:02:13
          +0100
Received: from zeus.nt.op.dlr.de (pcdn183_nt_op [129.247.173.183]) by
          zeus.nt.op.dlr.de (8.9.1b+Sun/8.9.1) with ESMTP id QAA03795 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 28 Nov 2000 16:02:09
          +0100 (MET)
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4B6BC00CD15FD2119E5F0008C7A419A50C613E9B@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Matteo Berioli <berioli@ZEUS.NT.OP.DLR.DE>
Message-ID:  <3A23C8F0.4520C0C1@zeus.nt.op.dlr.de>
Date:         Tue, 28 Nov 2000 16:02:09 +0100
Reply-To: mberio@libero.it
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Matteo Berioli <berioli@zeus.nt.op.dlr.de>
Subject:      Re: [MOBILE-IP] IPv6 user with Foreign Agent CoA!?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

"Hesham Soliman (EPA)" wrote:

> > Let us assume that I am an IPv6 mobile host, and I usually decapsulate
> > datagrams
> > coming from my Home Agent by myself, since in IPv6 only
> > Co-located Care-of Addresses exist.
> >
> > During my motion, I have to attach myself to a Mobile Router.
> > It has got only one Co-located Care-of Address and it
> > has to manage with it the whole mobile network that is behind it.
> > This is not a problem, since it can assign to all
> > the hosts of the mobile network, a Foreign Agent CoA, and in order to
> > correctly forward the packets, it can decapsulate the datagrams and
> > look at the home addresses in the inner headers.
> >
> > But this time it cannot assign to me my own Co-located Care-of Address,
> > even if I am an IPv6 host and I would wish to acquire only Co-located
> > CoAes.
> > As a matter of fact all the hosts attached to this mobile router have
> > to share the only CoA assigned to it.
> > So the mobile router will decapsulate also the datagrams directed to me,
> >
> > and it will forward them directly on the network, without encapsulation.
> >
> > The question is:
> > Is that a problem, if I receive already decapsulated datagrams, even
> > if usually I decapsulate them by myself?!
> >
> > Clarifications are welcome.
> >
>         => Your scenario is supported in draft-ietf-mobileip-hmipv6-02
>         which will be on the web very soon. I think you'll get the answer
>         you're looking for there.
>         But as a short answer, no there is no problem because the MN
>         doesn't think that it moved since it is still sending and receiving
>         packets using its Home address.

The problem is just this:
I would like the MN to know it moved, so it can update its CNs and its Home
Agent by itself.
As a matter of fact the router to which the MN is attached, cannot know its
CNs, so only the MN can inform them of the new CoA.
So I would desire to communicate to the MN the CoA, so it can update its CNs;
but I would also like it to be able to receive already decapsulated datagrams.

Thanks,
regards,
Matteo


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 10:24:05 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19613
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 10:24:04 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBB63@standards.nortelnetworks.com>; Tue, 28 Nov 2000 10:05:00 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 140054 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 10:05:00
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBBB61@standards.nortelnetworks.com>;
          Tue, 28 Nov 2000 10:04:59 -0500
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id IAA13919; Tue, 28 Nov 2000 08:22:10
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          HAA22168; Tue, 28 Nov 2000 07:22:10 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id HAA19102; Tue, 28 Nov 2000 07:22:08
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Pat Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.975424751.5862.pcalhoun@nasnfs>
Date:         Tue, 28 Nov 2000 07:19:11 -0800
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approach
              hes
X-To:         Eunsoo Shim <eunsoo@ctr.columbia.edu>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" <02ba01c058e1$5cafb9c0$6401a8c0@SOLID>

> [eunsoo]
> In CDMA's soft handoff mechanisms, the MN provides id of the new BS in the
> link layer message to the old BS.
> So if the FA has access all the contents of the link layer messages to the
> BS or they are the same entity as you said in the above, the FA would be
> able to figure out IP address of the new FA or the old FA from configuration
> or other similar mechanisms.
> Recently I saw slides showing the all IP approaches in the 3GPP2, which put
> BCS and PCF between BS and PDSN. It seems to me they want to put FA at PDSN.
> I don't know all the details of the interfaces between each entity and what
> information is transferred between them. But it does not look obvious that
> the FA has access to all the information each BS gets. Actually you said
> there might be need for 'slight' modification in a previous email. I copied
> that part from your email in the below.

You are correct, the FA is in the PSDN, and not in the BSC. However, there are
a couple of things to consider:

1. The PCF runs a protocol known as the R-P protocol. Proactive FA is very
well suited for this purpose. This is similar to the PDSN being a GFA, and the
PCF being an FA. (It is slightly more complicated than this, but it is
sufficient to state that proactive works because the PCF receives the link
layer triggers from the BSC).

2. As the work in OpenRAN continues, it is likely that IP will be introduced
in the RAN. Once this is done, a BSC may be a likely Foreign Agent.


> ------------------------
> <copied from one of Ajoy's messages>
> > -> Even in case of CDMA network, FA is not collocated with radio quipment.
> > We all agree that some changes are required at network side to
> > get trigger at source/target Foreign agent. For example, in case of CDMA
> > 2000, we might
> > have to make slight modification to R-P interface to send foreign agent
> > address
> > from PCF to PDSN. Similarly, we have to make some changes where FA is not
> > collocated
> > with radio equipment. The exact nature of changes will be dependent upon
> > the
> > specific technology and should be decided by respective SDOs.
> ------------------------
>
> If 3GPP2 people put FA on BS, this would disappear again I guess.

Correct, but proactive is still useful on the PCF.

> Probably it can be argued that this is a matter of network configuration or
> implementation.
> I wonder whether it is a simple issue for them to change the location of the
> FA from the PDSN to the BS.
> I hope it is.

Not in the short term, but again it isn't necessary.

> Still I have some questions.
> How about 3GPP?

I do not have an answer to this question because I concentrate on P2. I have
heard that 3GPP is very reluctant to make use of Mobile IP within their
networks, but have considered using a Foreign Agent at their network boundary.
If they aren't using Mobile IP, then I am not sure that anyone has an answer
to this question.

DISCLAIMER: I don't participate in 3GPP meetings, so things may have changed
in the past months.

> I think CDMA will be a dominent wireless link technologies in the near
> future since all 3G technologies are based on CDMA and also WLAN is. Due to
> its soft handoff capability, the new BS's ID and other similar information
> can be retrieved from the old BS.
> Can we assume this kind of soft handoff is generally available in the
> current or future wireless technologies? Isn't it a special case considering
> many kinds of wireless network technologies?

I believe that a wireless technology that does not have a proper handoff
mechanism is flawed, so I hope the answer is no (but I am willing to be proven
wrong).

> Also such capability is not
> available with GSM. People say 2G network won't disappear very soon. Do we
> exclude GSM or other non-CDMA wireless networks from our handoff design?

I believe that people with expertise in such networks need to step up to the
plate, and help us in our design. However, we MUST consider the networks that
do NOT provide sufficient time for the mobile to start reacting, and this is
what proactive FA assumes. In networks where the mobile is instructed to
handoff (immediately), proposals that require the mobile to interact with the
network will NOT work. In networks that DO provide time for the mobile to
interact, then proactive FA would work anyways. Right?

>
> I am not sure whether supporting WCDMA, CDMA2000 and WLAN (802.11 probably)
> is good enough. Am I bringing in non-practical concerns?

Not at all. My point all along was to get people to being in concrete examples
where things wouldn't work, and no one has yet to do so. I am talking about
examples where the link layer COULD NOT work with proactive FA, not
implementation issues of co-locating an FA with an access point.

Again, the co-authors of the proactive FA I-D are more than willing to work
with any concerns, and tweak the protocol as needed. We welcome comments such
as these, but non-fact based hand-waving is not all that useful (which is NOT
what this e-mail was about, but some other threads certainly fall within that
realm :(

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 10:31:40 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22430
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 10:31:40 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBB8D@standards.nortelnetworks.com>; Tue, 28 Nov 2000 10:08:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 140108 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 10:08:58
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBBB8B@standards.nortelnetworks.com>;
          Tue, 28 Nov 2000 10:08:57 -0500
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id IAA16741 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 28 Nov 2000 08:26:09
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          HAA23029; Tue, 28 Nov 2000 07:26:08 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id HAA19190; Tue, 28 Nov 2000 07:26:03
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Pat Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.975424985.16552.pcalhoun@nasnfs>
Date:         Tue, 28 Nov 2000 07:23:05 -0800
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
              h hes
X-To:         "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <5F05C89FB2F8D211B6430008C791912707460302@esealnt190>

> > I am not sure whether supporting WCDMA, CDMA2000 and WLAN
> > (802.11 probably)
> > is good enough. Am I bringing in non-practical concerns?
> >
>
> I agree that the method to speed up handoffs should be generic
> to support multiple technologies and not only consider specific
> systems. In fact this is one of the assumptions in the handoffs
> work although there have been a number of technology/system specific
> issues which have been brought up.

Yes, and these system specific issues were brought up to point out that a
particular proposal did not work in certain cases. One great example is where
the network does not allow ANY time for the mobile to interact with the
network during a handoff, but rather is instructed to handoff.

I think that to come up with a truly generic mechanism is flawed if we ignore
the fact that it cannot work with certain technologies.

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 10:31:41 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22439
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 10:31:41 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBBCB@standards.nortelnetworks.com>; Tue, 28 Nov 2000 10:14:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 140196 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 10:14:12
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBBBC8@standards.nortelnetworks.com>;
          Tue, 28 Nov 2000 10:14:11 -0500
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id IAA19953 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 28 Nov 2000 08:31:25
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          HAA24403; Tue, 28 Nov 2000 07:31:24 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id HAA19306; Tue, 28 Nov 2000 07:31:23
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Pat Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.975425306.6292.pcalhoun@nasnfs>
Date:         Tue, 28 Nov 2000 07:28:26 -0800
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
              hes
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <4B6BC00CD15FD2119E5F0008C7A419A50C613E9E@eaubrnt018.epa.ericsson.se>

> >
> > sorry, but I don't buy this one. The fact that *some* existing WLAN APs
> > are
> > not systems is really an implementation issue.
> >
>         => "some" ? The "majority" is a better word I think.
>         I agree it is a configuration issue but it seems that
>         this configuraton is very popular.

Find, majority. However, how can a Foreign Agent perform ANY fast handoff
scheme if it has NO idea that a mobile is about, or has, moved? The best you
can do is RFC 2002. So, for non colocated APs, RFC 2002 is what you get. If
you combine the functions, then you can provide quick handoff (again, I use
quick here because if I say fast, it sounds like I am talking about your
proposal, but I really mean fast).

I think that majority will become some when vendors have to compete with
products that DO provide faster handoffs.

>
> > Cisco's 802.11 AP includes
> > Mobile IP Foreign Agent functionality. No link layer changes are required.
> >
>         => Ok ! So to be accurate we can say that in the case of WLAN
>         the proactive approach will only work if the AP and the FA are
> colocated.
>         This is exactly what I'm trying to explain, the proactive approach
> only
>         works for certain architectures. This is a new limitation to MIP
> that we
>         didn't have before. So for the cases where the FA is not aware of
> the
>         L2 mobility (eg. most WLANs and 3GPP) , this approach doesn't work.
>         In 3GPP the FA is not aware of the degradation in the radio link,
> and does
>         not get that L2 trigger. Therefore I don't think that this approach
> will
>         work their either.
>

In 3GPP2 it DOES via a protocol used between the BSC/PCF and the FA. It
doesn't receive the triggers directly, but rather through a signalling
protocol. Does 3GPP NOT have an equivalent protocol? btw, one could also
design such a protocol between the AP and the FA, if need be.

Of course, as far as I know, 3GPP has no intentions of using Mobile IP :(

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 10:46:07 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27875
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 10:46:06 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBC5A@standards.nortelnetworks.com>; Tue, 28 Nov 2000 10:26:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 140393 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 10:26:53
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:62807) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBBC58@standards.nortelnetworks.com>; Tue, 28 Nov 2000
          10:26:52 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id CAA24886 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Nov 2000 02:40:33
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id CAA21245 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Nov 2000 02:43:26
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD6QBL>; Wed, 29 Nov 2000 02:43:42 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613EA2@eaubrnt018.epa.ericsson.se>
Date:         Wed, 29 Nov 2000 02:43:42 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac
              hes
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> > > sorry, but I don't buy this one. The fact that *some* existing WLAN
> APs
> > > are
> > > not systems is really an implementation issue.
> > >
> >         => "some" ? The "majority" is a better word I think.
> >         I agree it is a configuration issue but it seems that
> >         this configuraton is very popular.
>
> Find, majority. However, how can a Foreign Agent perform ANY fast handoff
> scheme if it has NO idea that a mobile is about, or has, moved? The best
> you
> can do is RFC 2002. So, for non colocated APs, RFC 2002 is what you get.
> If
> you combine the functions, then you can provide quick handoff (again, I
> use
> quick here because if I say fast, it sounds like I am talking about your
> proposal, but I really mean fast).
>
        => You lost me here, if you combine which funtions ?
        RFC 2002 with some optimisation (anticipation and bicasting) is
        enough, I agree with that. I also think it's enough for the other
        case where the FA is colocated with the AP.
        I still haven't heard a concrete argument on why it is not enough.

> I think that majority will become some when vendors have to compete with
> products that DO provide faster handoffs.
>
> >
> > > Cisco's 802.11 AP includes
> > > Mobile IP Foreign Agent functionality. No link layer changes are
> required.
> > >
> >         => Ok ! So to be accurate we can say that in the case of WLAN
> >         the proactive approach will only work if the AP and the FA are
> > colocated.
> >         This is exactly what I'm trying to explain, the proactive
> approach
> > only
> >         works for certain architectures. This is a new limitation to MIP
> > that we
> >         didn't have before. So for the cases where the FA is not aware
> of
> > the
> >         L2 mobility (eg. most WLANs and 3GPP) , this approach doesn't
> work.
> >         In 3GPP the FA is not aware of the degradation in the radio
> link,
> > and does
> >         not get that L2 trigger. Therefore I don't think that this
> approach
> > will
> >         work their either.
> >
>
> In 3GPP2 it DOES via a protocol used between the BSC/PCF and the FA. It
> doesn't receive the triggers directly, but rather through a signalling
> protocol.
>
        => I know that and I wasn't referring to 3GPP2.

> Does 3GPP NOT have an equivalent protocol? btw, one could also
> design such a protocol between the AP and the FA, if need be.
>
        => I'm talking about an existing system. I'm assuming we want
        the fast handoffs (not Fast Handoffs) to work with existing systems
?

> Of course, as far as I know, 3GPP has no intentions of using Mobile IP :(
>
        => That's not correct, MIP is supported in the standard. Rel 99 to
be exact.

        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 10:56:53 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02782
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 10:56:53 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBC9E@standards.nortelnetworks.com>; Tue, 28 Nov 2000 10:33:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 140484 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 10:33:58
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:62859) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBBC9C@standards.nortelnetworks.com>; Tue, 28 Nov 2000
          10:33:57 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id CAA25009 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Nov 2000 02:47:42
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id CAA21759 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Nov 2000 02:50:35
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD6QFV>; Wed, 29 Nov 2000 02:50:51 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613EA3@eaubrnt018.epa.ericsson.se>
Date:         Wed, 29 Nov 2000 02:50:51 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] IPv6 user with Foreign Agent CoA!?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> > > The question is:
> > > Is that a problem, if I receive already decapsulated datagrams, even
> > > if usually I decapsulate them by myself?!
> > >
> > > Clarifications are welcome.
> > >
> >         => Your scenario is supported in draft-ietf-mobileip-hmipv6-02
> >         which will be on the web very soon. I think you'll get the
> answer
> >         you're looking for there.
> >         But as a short answer, no there is no problem because the MN
> >         doesn't think that it moved since it is still sending and
> receiving
> >         packets using its Home address.
>
> The problem is just this:
> I would like the MN to know it moved, so it can update its CNs and its
> Home
> Agent by itself.
>
        => I realise that. That's exactly what the draft allows you to do.
        The MAP option is sent by the Mobile Router (MR), so the MN
        knows that it moved and that the MAP acts as a COA for it.
        The MN will update the HA and the CNs accordingly with an
        alternate-COA as specified in MIPv6. So route optimised
        packets will be received by the MAP (MR) and forwarded
        to the MN. Every thing happens end to end.
        Does that solve your problem ?
        Please see the draft for more info.

        Regards,
        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 10:56:55 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02799
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 10:56:54 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBCB7@standards.nortelnetworks.com>; Tue, 28 Nov 2000 10:36:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 140512 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 10:36:31
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBBCB5@standards.nortelnetworks.com>; Tue, 28 Nov 2000 10:36:31
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA00337;
          Tue, 28 Nov 2000 07:53:25 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eASFrM714724; Tue, 28 Nov 2000 07:53:22
          -0800
X-Virus-Scanned:  Tue, 28 Nov 2000 07:53:22 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdsx3gcY; Tue, 28 Nov 2000
          07:53:13 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <7695E2F6903F7A41961F8CF888D87EA81C9BD1@red-msg-06.redmond.corp.microsoft.com>
            <3A1BCC4E.D00423AE@rd.francetelecom.fr>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A23D4EB.CC119E99@iprg.nokia.com>
Date:         Tue, 28 Nov 2000 07:53:15 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile
              IPv6:draft-ietf-mobileip-ipv6-13.txt
X-cc:         Jean-Michel COMBES <jeanmichel.combes@rd.francetelecom.fr>,
              "Basavaraj Patil (NTC/Dallas)" <Basavaraj.Patil@nokia.com>,
              Phil Roberts <qa3445@email.mot.com>,
              Dave Johnson <dbj@cs.rice.edu>, David Oran <oran@cisco.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

Hello folks,

Is it really acceptable to strip out all the mandates for authentication
methods, and just make a blanket statement that authentication is
necessary without saying how to do it?  Perhaps the need for having
a common method (for interoperability) is already mandated just by
the fact that IPv6 mandates implementation of AH and ESP.  We already
don't say how the keys are to be distributed.  Presumably the same
method that causes the keys to be distributed would also determine
whether AH or ESP is to be used.

If that can be represented as working-group consensus, I will go about
the process of making a new draft revision for Mobile IPv6.  I don't
see any technical reason standing in the way of this approach, but
before making the revisions I hope someone will tell me if it has
some problems that I don't see right now.  Or, alternatively, that
more people would express a technical confidence that relaxing the
restrictions is O.K.

I wonder if this can be considered to be a clarification suggested
by comments received during Last Call, or whether instead a new
working group Last Call would have to be issued.

Regards,
Charlie P.



Jean-Michel COMBES wrote:
>
> Hi,
>
> Richard Draves a écrit :
>
> > I have two main issues with draft-ietf-mobileip-ipv6-13.txt.
> >
> > 1. The draft is very clear & unambiguous (which is good) about the IPsec
> > headers, but I still respectfully disagree. Mandating AH to protect Binding
> > Updates is too restrictive.
>
> JMC :
> I agree that's too restrictive perhaps.
>
> > It is quite feasible to allow for either AH or
> > ESP.
>
> JMC :
> Agree,
> - AH/transport
> or
> - ESP/tunnel (with null encryption)
>
> > In recent discussions of this on the ipsec list, a couple other people
> > (Henry Spencer [henry@spsystems.net], Markku Savela
> > [Markku.Savela@research.nokia.com]) have agreed with me on this point.
>
> JMC :
> Perhaps, it would be better just to say in the draft that BU and BAck MUST be
> authenticated without specifying how, everyone choosing his policy (see above).


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 11:21:08 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14525
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 11:21:02 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBDA8@standards.nortelnetworks.com>; Tue, 28 Nov 2000 11:00:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 140839 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 11:00:14
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:63094) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBBDA5@standards.nortelnetworks.com>; Tue, 28 Nov 2000
          11:00:13 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id DAA25718 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Nov 2000 03:13:58
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id DAA23747 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Nov 2000 03:16:51
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD6QWJ>; Wed, 29 Nov 2000 03:17:07 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613EA6@eaubrnt018.epa.ericsson.se>
Date:         Wed, 29 Nov 2000 03:17:07 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile IPv6:draft-ietf-mobileip-ipv
              6-13.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA14525

Hello Charlie, 

If I understand you correctly, you're saying we should allow 
either ESP or AH. And that since IPv6 supports both
then there shouldn't be an interoperability problem. 

To be able to for an opinion I need to ask a couple of questions 
about IPsec. 
I thought that ESP would authenticate everything below the ESP
header and not before it ? Is that correct ?
If that's not correct then why was AH chosen in the first place ?

If ESP can authenticate the entire packet then I don't see 
a problem with your suggestion, but I'd like to know why
AH was chosen over ESP. 

Regards,
Hesham

> -----Original Message-----
> From: Charles E. Perkins [SMTP:charliep@IPRG.nokia.com]
> Sent: Wednesday, 29 November 2000 2:53
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: [MOBILE-IP] WG Last Call: Mobile
> IPv6:draft-ietf-mobileip-ipv6-13.txt
> 
> Hello folks,
> 
> Is it really acceptable to strip out all the mandates for authentication
> methods, and just make a blanket statement that authentication is
> necessary without saying how to do it?  Perhaps the need for having
> a common method (for interoperability) is already mandated just by
> the fact that IPv6 mandates implementation of AH and ESP.  We already
> don't say how the keys are to be distributed.  Presumably the same
> method that causes the keys to be distributed would also determine
> whether AH or ESP is to be used.
> 
> If that can be represented as working-group consensus, I will go about
> the process of making a new draft revision for Mobile IPv6.  I don't
> see any technical reason standing in the way of this approach, but
> before making the revisions I hope someone will tell me if it has
> some problems that I don't see right now.  Or, alternatively, that
> more people would express a technical confidence that relaxing the
> restrictions is O.K.
> 
> I wonder if this can be considered to be a clarification suggested
> by comments received during Last Call, or whether instead a new
> working group Last Call would have to be issued.
> 
> Regards,
> Charlie P.
> 
> 
> 
> Jean-Michel COMBES wrote:
> >
> > Hi,
> >
> > Richard Draves a écrit :
> >
> > > I have two main issues with draft-ietf-mobileip-ipv6-13.txt.
> > >
> > > 1. The draft is very clear & unambiguous (which is good) about the
> IPsec
> > > headers, but I still respectfully disagree. Mandating AH to protect
> Binding
> > > Updates is too restrictive.
> >
> > JMC :
> > I agree that's too restrictive perhaps.
> >
> > > It is quite feasible to allow for either AH or
> > > ESP.
> >
> > JMC :
> > Agree,
> > - AH/transport
> > or
> > - ESP/tunnel (with null encryption)
> >
> > > In recent discussions of this on the ipsec list, a couple other people
> > > (Henry Spencer [henry@spsystems.net], Markku Savela
> > > [Markku.Savela@research.nokia.com]) have agreed with me on this point.
> >
> > JMC :
> > Perhaps, it would be better just to say in the draft that BU and BAck
> MUST be
> > authenticated without specifying how, everyone choosing his policy (see
> above).


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 11:36:57 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21962
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 11:36:56 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBE06@standards.nortelnetworks.com>; Tue, 28 Nov 2000 11:16:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 140963 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 11:16:22
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBBE04@standards.nortelnetworks.com>; Tue, 28 Nov 2000 11:16:22
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA04400;
          Tue, 28 Nov 2000 08:33:36 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eASGXZw28642; Tue, 28 Nov 2000 08:33:35
          -0800
X-Virus-Scanned:  Tue, 28 Nov 2000 08:33:35 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdz5YBoM; Tue, 28 Nov 2000
          08:33:26 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <4B6BC00CD15FD2119E5F0008C7A419A50C613EA6@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A23DE57.BB747E82@iprg.nokia.com>
Date:         Tue, 28 Nov 2000 08:33:27 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile
              IPv6:draft-ietf-mobileip-ipv6-13.txt
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

Hello Hesham,

> If I understand you correctly, you're saying we should allow
> either ESP or AH. And that since IPv6 supports both
> then there shouldn't be an interoperability problem.

Correct.

> To be able to for an opinion I need to ask a couple of questions
> about IPsec.
> I thought that ESP would authenticate everything below the ESP
> header and not before it ? Is that correct ?
> If that's not correct then why was AH chosen in the first place ?

As indicated in Jean-Michel's original note, ESP is used in tunnel
mode, so that the entire inner packet is authenticated.  AH takes
less space, which is why it was originally chosen.

Regards,
Charlie P.


>
> > -----Original Message-----
> > From: Charles E. Perkins [SMTP:charliep@IPRG.nokia.com]
> > Sent: Wednesday, 29 November 2000 2:53
> > To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > Subject:      Re: [MOBILE-IP] WG Last Call: Mobile
> > IPv6:draft-ietf-mobileip-ipv6-13.txt
> >
> > Hello folks,
> >
> > Is it really acceptable to strip out all the mandates for authentication
> > methods, and just make a blanket statement that authentication is
> > necessary without saying how to do it?  Perhaps the need for having
> > a common method (for interoperability) is already mandated just by
> > the fact that IPv6 mandates implementation of AH and ESP.  We already
> > don't say how the keys are to be distributed.  Presumably the same
> > method that causes the keys to be distributed would also determine
> > whether AH or ESP is to be used.
> >
> > If that can be represented as working-group consensus, I will go about
> > the process of making a new draft revision for Mobile IPv6.  I don't
> > see any technical reason standing in the way of this approach, but
> > before making the revisions I hope someone will tell me if it has
> > some problems that I don't see right now.  Or, alternatively, that
> > more people would express a technical confidence that relaxing the
> > restrictions is O.K.
> >
> > I wonder if this can be considered to be a clarification suggested
> > by comments received during Last Call, or whether instead a new
> > working group Last Call would have to be issued.
> >
> > Regards,
> > Charlie P.
> >
> >
> >
> > Jean-Michel COMBES wrote:
> > >
> > > Hi,
> > >
> > > Richard Draves a écrit :
> > >
> > > > I have two main issues with draft-ietf-mobileip-ipv6-13.txt.
> > > >
> > > > 1. The draft is very clear & unambiguous (which is good) about the
> > IPsec
> > > > headers, but I still respectfully disagree. Mandating AH to protect
> > Binding
> > > > Updates is too restrictive.
> > >
> > > JMC :
> > > I agree that's too restrictive perhaps.
> > >
> > > > It is quite feasible to allow for either AH or
> > > > ESP.
> > >
> > > JMC :
> > > Agree,
> > > - AH/transport
> > > or
> > > - ESP/tunnel (with null encryption)
> > >
> > > > In recent discussions of this on the ipsec list, a couple other people
> > > > (Henry Spencer [henry@spsystems.net], Markku Savela
> > > > [Markku.Savela@research.nokia.com]) have agreed with me on this point.
> > >
> > > JMC :
> > > Perhaps, it would be better just to say in the draft that BU and BAck
> > MUST be
> > > authenticated without specifying how, everyone choosing his policy (see
> > above).


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 11:44:02 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25030
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 11:44:01 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBE3A@standards.nortelnetworks.com>; Tue, 28 Nov 2000 11:21:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 141033 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 11:21:19
          -0500
Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBBE38@standards.nortelnetworks.com>; Tue, 28 Nov 2000 11:21:19
          -0500
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA25345 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 28 Nov 2000 09:38:33
          -0700 (MST)]
Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102])
          by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA10823 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 28 Nov 2000 09:38:33
          -0700 (MST)]
Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id
          <WMS1GGCX>; Tue, 28 Nov 2000 10:38:32 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain
Approved-By:  Roberts Philip-qa3445 <Philip_Roberts-qa3445@EMAIL.MOT.COM>
Message-ID:  <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D305@il27exm03.cig.mot.com>
Date:         Tue, 28 Nov 2000 10:38:31 -0600
Reply-To: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Subject:      [MOBILE-IP] draft agenda
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Here it is, folks.  We have some specific goals we'd like to accomplish at this meeting and the time will be made available to get those done.  We'd like to get the v6 draft wrapped up.  It's in last call now and we'd like to reconcile all remaining issues by the end of the San Diego meeting.  We'd like to reach agreement on a single draft to be working group document for MIP v4 fast handoff.  We'd like to reach agreement on a single draft to be working group document for MIP v6 fast handoff.


Thursday 9-11:30 (150 minutes)
Raj             10      Agenda bashing and wg document status
Charlie Perkins 15      MIPv6 Update                            draft-ietf-mobileip-ipv6-13.txt
Vijay Devarapali        5       MIPv6 ETSI Bake-off Report

Mobile IP V4 fast handoff:
Pat Calhoun     5       Proactive handoff                               draft-calhoun-mobileip-proactive-fa-02.txt
Hesham Soliman  5       Fast handoff                            draft-elmalki-mobileip-fast-handoffs-03.txt
McCann/Soliman  5       Summary  of differences in v4 handoff
WG              15      Discussion of fast handoff in v4

Mobile IP V6 fast handoff:
Charlie Perkins 15      v6 fast handoff design team



Hesham Soliman  10      Hierarchical MIP v6                     draft-ietf-mobileip-hmipv6-01.txt
Pat Calhoun     5       Mobile IP and GRE enhancements          draft-calhoun-mobileip-gre-ext-00.txt
Charlie Perkins 10      DIAMETER extensions for MIP             draft-calhoun-diameter-mobileip-11.txt
Charlie Perkins 10      AAAv6 for MIP
Steve Glass     15      Registration Revocation for Mobile IP   draft-glass-mobileip-reg-revok-00.txt
Samita Chakrabarti 10   Private addressing                              draft-ietf-mobileip-rfc2344-bis-03.txt

Friday 9-11:30 (150 minutes)
Hemant Chaskar  10      A Framework for QoS Support in MIP v6   draft-chaskar-mobileip-qos-00.txt
Glenn Morrow    15      Intercepting Location Updates           draft-lmk-mobileip-intercepting-update-00.txt
Hesham Soliman  10      Security association establishment for route optimization in v6 draft-soliman-mobileip-routeopt-mipv6-00.txt
Charlie Pekins  10      IP v6 Regional Registration             draft-malinen-mobileip-regreg6-00.txt
SL Tsao         15      Introducing Mobile IP in IPv4/IPv6 Interconnected networks                                      draft-tsao-mobileip-duelstack-model-00.txt
Steve Glass     10      Use of DHCP in Mobile IP                draft-glass-mobileip-agent-dhcp-proxy-00.txt
Ernst Thierry   10      Mobile Network Support                  draft-ernst-mobileip-v6-network-00.txt
Jari Malinen    5       GSM SIM authentication                  draft-haverinen-mobileip-gsmsim-00.txt
Jiwoong Lee     6       SGM support in MIP                      draft-lee-sgm-support-mobileip-00.txt


Pekka Nikander  10      Mobile IP v6 for the Homeless           draft-nikander-mobileip-homelessv6-00.txt
Behcet Sarikaya 5       Mobile IP v6 Regional Paging            draft-sarikaya-mobileip-hmipv6rp-00



From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 12:03:02 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01665
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 12:03:01 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBEB9@standards.nortelnetworks.com>; Tue, 28 Nov 2000 11:43:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 141208 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 11:43:39
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:63400) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBBEB7@standards.nortelnetworks.com>; Tue, 28 Nov 2000
          11:43:38 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id DAA26556 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Nov 2000 03:57:23
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id EAA26671 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Nov 2000 04:00:16
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD6RQX>; Wed, 29 Nov 2000 04:00:32 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613EAA@eaubrnt018.epa.ericsson.se>
Date:         Wed, 29 Nov 2000 04:00:33 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile IPv6:draft-ietf-mobileip-ipv
              6-13.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

        Hello Charlie,


> > To be able to for an opinion I need to ask a couple of questions
> > about IPsec.
> > I thought that ESP would authenticate everything below the ESP
> > header and not before it ? Is that correct ?
> > If that's not correct then why was AH chosen in the first place ?
>
> As indicated in Jean-Michel's original note, ESP is used in tunnel
> mode, so that the entire inner packet is authenticated.  AH takes
> less space, which is why it was originally chosen.
>
        => I see. I don't have a problem with that as long as the draft
        specifies that the MN follows the normal sending rules.
        Ie. the outer packet contains the Home address option
        and if the CN is a MN for which the MN  (sending th BU)
        has a BC entry, then a routing header should be included as usual.

        Regards,
        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 12:50:25 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15355
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 12:50:24 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBF84@standards.nortelnetworks.com>; Tue, 28 Nov 2000 12:28:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 141463 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 12:28:42
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBBF82@standards.nortelnetworks.com>;
          Tue, 28 Nov 2000 12:28:42 -0500
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id KAA20317; Tue, 28 Nov 2000 10:45:55
          -0700 (MST)
Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by
          engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          JAA22801; Tue, 28 Nov 2000 09:45:54 -0800 (PST)
Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id
          eASHilL00440; Tue, 28 Nov 2000 09:44:47 -0800 (PST)
X-Sun-Charset: ISO-8859-1
Approved-By:  Mohan Parthasarathy <Mohan.Parthasarathy@ENG.SUN.COM>
Message-ID:  <200011281744.eASHilL00440@locked.eng.sun.com>
Date:         Tue, 28 Nov 2000 09:44:47 -0800
Reply-To: Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com>
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile
              IPv6:draft-ietf-mobileip-ipv6-13.txt
X-To:         charliep@IPRG.nokia.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> F >
> Hello folks,
>
> Is it really acceptable to strip out all the mandates for authentication
> methods, and just make a blanket statement that authentication is
> necessary without saying how to do it?  Perhaps the need for having
> a common method (for interoperability) is already mandated just by
> the fact that IPv6 mandates implementation of AH and ESP.  We already
> don't say how the keys are to be distributed.  Presumably the same
> method that causes the keys to be distributed would also determine
> whether AH or ESP is to be used.
>
> If that can be represented as working-group consensus, I will go about
> the process of making a new draft revision for Mobile IPv6.  I don't
> see any technical reason standing in the way of this approach, but
> before making the revisions I hope someone will tell me if it has
> some problems that I don't see right now.  Or, alternatively, that
> more people would express a technical confidence that relaxing the
> restrictions is O.K.
>

If ESP is used you MUST use the alternate care of address option
and the binding update should appear after the ESP header. With this
the restriction can be relaxed to use ESP. If you just say
"authentication required", it will not help the implementors in
anyway.

-mohan

> I wonder if this can be considered to be a clarification suggested
> by comments received during Last Call, or whether instead a new
> working group Last Call would have to be issued.
>
> Regards,
> Charlie P.
>
>
>
> Jean-Michel COMBES wrote:
> >
> > Hi,
> >
> > Richard Draves a écrit :
> >
> > > I have two main issues with draft-ietf-mobileip-ipv6-13.txt.
> > >
> > > 1. The draft is very clear & unambiguous (which is good) about the IPsec
> > > headers, but I still respectfully disagree. Mandating AH to protect Binding
> > > Updates is too restrictive.
> >
> > JMC :
> > I agree that's too restrictive perhaps.
> >
> > > It is quite feasible to allow for either AH or
> > > ESP.
> >
> > JMC :
> > Agree,
> > - AH/transport
> > or
> > - ESP/tunnel (with null encryption)
> >
> > > In recent discussions of this on the ipsec list, a couple other people
> > > (Henry Spencer [henry@spsystems.net], Markku Savela
> > > [Markku.Savela@research.nokia.com]) have agreed with me on this point.
> >
> > JMC :
> > Perhaps, it would be better just to say in the draft that BU and BAck MUST be
> > authenticated without specifying how, everyone choosing his policy (see above).
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 12:57:22 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17376
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 12:57:22 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBFFC@standards.nortelnetworks.com>; Tue, 28 Nov 2000 12:38:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 141625 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 12:38:01
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBBFFA@standards.nortelnetworks.com>; Tue, 28 Nov 2000 12:38:00
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA12337
          for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 28 Nov 2000
          09:55:15 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eASHtBS30667 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 28 Nov 2000 09:55:11
          -0800
X-Virus-Scanned:  Tue, 28 Nov 2000 09:55:11 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpds7TivY; Tue, 28 Nov 2000
          09:54:59 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <4B6BC00CD15FD2119E5F0008C7A419A50C613EA3@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A23F176.3A047674@iprg.nokia.com>
Date:         Tue, 28 Nov 2000 09:55:02 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      [MOBILE-IP] IPv6 mobile routers vs. regional mobility agents
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello,

I think there's another way to look at this problem of
mobile routers that offers a "better" solution.  It isn't
the same problem as has been discussed in connection with
hiearchical mobility agents.  It should not be solved by
techniques associated with hierarchical mobility agents.
Nor anchor points, if I may use that terminology.  A mobile
router should not necessarily be considered an anchor point
or a regional mobility agent.

The reason it is not the same is as follows:

- With hierarchical mobility agents, the mobile node's home
  agent can be shielded from having to know about local
  care-of addresses, as long as it can supply a regional
  care-of address to the home agent and supply local care-of
  addresses to the regional mobility agent.

- With mobile routers, the mobile node "should" be using
  the prefix of a home address of the mobile router as the
  prefix by which it forms its own care-of address.  This
  could be done independently of any sort of hierarchical
  mobility agent architecture.  In other words, there doesn't
  have to be any regional mobility agent at all to make
  a mobile router work.

To see this in another way, suppose that the mobile router
has a fixed Ethernet attached to it.  The nodes on the
"mobile network" do not run Mobile IPv6.  Why should they
deal with any advertised care-of addresses from the mobile
router?

However, this business about mobile routers does bring up
interesting points.  Suppose the mobile node hooks up to
a mobile router, and gets a prefix from the advertisement,
and forms its care-of address.  Packets routed towards that
care-of address are likely to go through the home agent
for the mobile router.  The router's home agent will
encapsulate them.  The mobile router will decapsulate them.
At this point, the packet should be as issued originally
by the correspondent node (with a routing header) or
by the mobile node's home agent (i.e., encapsulated).

Now suppose some corrspondent node is sending megabytes of
data, with each packet having a routing header containing
the mobile node's care-of address.

We would like for that data not to have to go through the
home agent for the mobile router.  That means that the
correspondent node should get information about the care-of
address for the _mobile router_.  Then, the correspondent node
could put in a routing header with _two_ care-of addresses.
The first one would be the care-of address for the mobile
router, and the second one would be the care-of address
for the mobile node.

In order to do this directly, the mobile router would need
some security association with the correspondent node.
This is one area where this problem shows itself to be much
different than the hierarchical mobility agent problem.
For hierarchical mobility agents, there is a natural way
to set up the security associations.  For the mobile router,
the same security setup seems unlikely to work.  I didn't
"map" it out yet, but I reckon some sort of redirect is
the most likely candidate.  The mobile node can authentically
"relay" a redirect from the mobile router to the correspondent
node.  We would have to make some rules about this, but I
think that what the correspondent node would see would be
a Binding Update for the care-of address.  This has already
been specified in another context for smooth handovers.


I sure hope we don't have to do this before Mobile IPv6
completes its Last Call.

Regards,
Charlie P.



"Hesham Soliman (EPA)" wrote:
>
> > > > The question is:
> > > > Is that a problem, if I receive already decapsulated datagrams, even
> > > > if usually I decapsulate them by myself?!
> > > >
> > > > Clarifications are welcome.
> > > >
> > >         => Your scenario is supported in draft-ietf-mobileip-hmipv6-02
> > >         which will be on the web very soon. I think you'll get the
> > answer
> > >         you're looking for there.
> > >         But as a short answer, no there is no problem because the MN
> > >         doesn't think that it moved since it is still sending and
> > receiving
> > >         packets using its Home address.
> >
> > The problem is just this:
> > I would like the MN to know it moved, so it can update its CNs and its
> > Home
> > Agent by itself.
> >
>         => I realise that. That's exactly what the draft allows you to do.
>         The MAP option is sent by the Mobile Router (MR), so the MN
>         knows that it moved and that the MAP acts as a COA for it.
>         The MN will update the HA and the CNs accordingly with an
>         alternate-COA as specified in MIPv6. So route optimised
>         packets will be received by the MAP (MR) and forwarded
>         to the MN. Every thing happens end to end.
>         Does that solve your problem ?
>         Please see the draft for more info.
>
>         Regards,
>         Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 13:10:22 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22441
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 13:10:22 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC050@standards.nortelnetworks.com>; Tue, 28 Nov 2000 12:51:18 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 141743 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 12:51:17
          -0500
Received: from mail5.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBC04E@standards.nortelnetworks.com>; Tue, 28 Nov 2000 12:51:17
          -0500
Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall
          NT); Tue, 28 Nov 2000 10:08:32 -0800 (Pacific Standard Time)
Received: by inet-imc-05.redmond.corp.microsoft.com with Internet Mail Service
          (5.5.2651.58) id <XZL58MJ3>; Tue, 28 Nov 2000 10:08:32 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Approved-By:  Richard Draves <richdr@MICROSOFT.COM>
Message-ID:  <7695E2F6903F7A41961F8CF888D87EA801469885@red-msg-06.redmond.corp.microsoft.com>
Date:         Tue, 28 Nov 2000 10:07:47 -0800
Reply-To: Richard Draves <richdr@microsoft.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Richard Draves <richdr@microsoft.com>
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile IPv6:draft-ietf-mobileip-ipv
              6-13.txt
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I think the draft needs to be quite clear about the allowable packet header
arrangements and what addresses in which headers get used for security
policy checks. Being wishy-washy about what the packets can look like will
be very bad for interoperability.

Yes, IKE negotiation or manual configuration could choose between the use of
AH or ESP, besides choosing the specific transforms.

Rich

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Tuesday, November 28, 2000 7:53 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] WG Last Call: Mobile
> IPv6:draft-ietf-mobileip-ipv6-13.txt
>
>
> Hello folks,
>
> Is it really acceptable to strip out all the mandates for
> authentication
> methods, and just make a blanket statement that authentication is
> necessary without saying how to do it?  Perhaps the need for having
> a common method (for interoperability) is already mandated just by
> the fact that IPv6 mandates implementation of AH and ESP.  We already
> don't say how the keys are to be distributed.  Presumably the same
> method that causes the keys to be distributed would also determine
> whether AH or ESP is to be used.
>
> If that can be represented as working-group consensus, I will go about
> the process of making a new draft revision for Mobile IPv6.  I don't
> see any technical reason standing in the way of this approach, but
> before making the revisions I hope someone will tell me if it has
> some problems that I don't see right now.  Or, alternatively, that
> more people would express a technical confidence that relaxing the
> restrictions is O.K.
>
> I wonder if this can be considered to be a clarification suggested
> by comments received during Last Call, or whether instead a new
> working group Last Call would have to be issued.
>
> Regards,
> Charlie P.
>
>
>
> Jean-Michel COMBES wrote:
> >
> > Hi,
> >
> > Richard Draves a ecrit :
> >
> > > I have two main issues with draft-ietf-mobileip-ipv6-13.txt.
> > >
> > > 1. The draft is very clear & unambiguous (which is good)
> about the IPsec
> > > headers, but I still respectfully disagree. Mandating AH
> to protect Binding
> > > Updates is too restrictive.
> >
> > JMC :
> > I agree that's too restrictive perhaps.
> >
> > > It is quite feasible to allow for either AH or
> > > ESP.
> >
> > JMC :
> > Agree,
> > - AH/transport
> > or
> > - ESP/tunnel (with null encryption)
> >
> > > In recent discussions of this on the ipsec list, a couple
> other people
> > > (Henry Spencer [henry@spsystems.net], Markku Savela
> > > [Markku.Savela@research.nokia.com]) have agreed with me
> on this point.
> >
> > JMC :
> > Perhaps, it would be better just to say in the draft that
> BU and BAck MUST be
> > authenticated without specifying how, everyone choosing his
> policy (see above).
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 13:17:14 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24968
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 13:17:13 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC066@standards.nortelnetworks.com>; Tue, 28 Nov 2000 12:53:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 141770 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 12:53:13
          -0500
Received: from cs.rice.edu by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBC064@standards.nortelnetworks.com>;
          Tue, 28 Nov 2000 12:53:13 -0500
Received: from localhost (dbj@localhost) by cs.rice.edu (8.9.0/8.9.0) with
          ESMTP id MAA19755; Tue, 28 Nov 2000 12:10:23 -0600 (CST)
Approved-By:  dbj@CS.RICE.EDU
Message-ID:  <19754.975435023@cs.rice.edu>
Date:         Tue, 28 Nov 2000 12:10:23 -0600
Reply-To: Dave Johnson <dbj@cs.rice.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Dave Johnson <dbj@cs.rice.edu>
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile
              IPv6:draft-ietf-mobileip-ipv6-13.txt
X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
X-cc:         Jean-Michel COMBES <jeanmichel.combes@rd.francetelecom.fr>,
              "Basavaraj Patil (NTC/Dallas)" <Basavaraj.Patil@nokia.com>,
              Phil Roberts <qa3445@email.mot.com>, David Oran <oran@cisco.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of "Tue, 28 Nov 2000 07:53:15 PST" 
              <3A23D4EB.CC119E99@iprg.nokia.com>

>Hello folks,
>
>Is it really acceptable to strip out all the mandates for authentication
>methods, and just make a blanket statement that authentication is
>necessary without saying how to do it?  Perhaps the need for having
>a common method (for interoperability) is already mandated just by
>the fact that IPv6 mandates implementation of AH and ESP.  We already
>don't say how the keys are to be distributed.  Presumably the same
>method that causes the keys to be distributed would also determine
>whether AH or ESP is to be used.

Charlie,

That is exactly the way I used to have the draft worded -- for
exactly the reasons now being discussed.  However, the strong
consensus that developed seemed to be (at the time) that the draft
must be specific on how to use IPsec.  And the consensus (again, at
the time) seemed to be that it was possible to define how to use
ESP, but relative to AH, use of ESP was quite messy due to the
differences in what parts of the packet are protected by AH
vs. ESP.  The thinking was that use of ESP could be added later,
but that we wanted to get some version to Last Call and Proposed
Standard ASAP, so the draft only specified use of AH, and only
specified transport mode, not tunnel mode.  It is certainly
possible to define all the other combinations, but I think it is
also still important to reach closure soon on at least some version
of this and get it through the IESG.

                                        Dave

--
David B. Johnson, Associate Professor
of Computer Science and Electrical and Computer Engineering

Department of Computer Science - MS 132    dbj@cs.rice.edu
Rice University                            http://www.cs.rice.edu/~dbj/
6100 Main Street                           Phone: (713) 348-3063
Houston, Texas 77005-1892 USA              Fax:   (713) 348-5930


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 13:30:36 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29220
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 13:30:35 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC0D8@standards.nortelnetworks.com>; Tue, 28 Nov 2000 13:07:18 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 141925 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 13:07:17
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:64088) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBC0D6@standards.nortelnetworks.com>; Tue, 28 Nov 2000
          13:07:16 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id FAA28507 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Nov 2000 05:21:01
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id FAA02867 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Nov 2000 05:23:53
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD6THT>; Wed, 29 Nov 2000 05:24:11 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613EAC@eaubrnt018.epa.ericsson.se>
Date:         Wed, 29 Nov 2000 05:24:10 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] IPv6 mobile routers vs. regional mobility agents
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

        Hello Charlie,

        I hope you can help me follow this interesting analysis.


> I think there's another way to look at this problem of
> mobile routers that offers a "better" solution.  It isn't
> the same problem as has been discussed in connection with
> hiearchical mobility agents.  It should not be solved by
> techniques associated with hierarchical mobility agents.
> Nor anchor points, if I may use that terminology.  A mobile
> router should not necessarily be considered an anchor point
> or a regional mobility agent.
>
        => First I'd like to clarify the situation where an anchor
        point is needed. Consider a Personal Area Network
        (PAN). When that network attaches via one or more
        routers on that PAN to a foreign network, it may not be
        possible to obtain a topologically correct preftx to allow
        this PAN to use topologically correct addresses.
        So this is the problem I assumed we were looking at
        in the previous thread. So the case is : the MN has
        physically moved but not topologically. It needs to map
        the physical movement into a topological one.
        No hierarchy is needed here. Just a topologically correct
        COA. It just happens that we can use an anchor point's
        address for that purpose. No hierarchy of anchor points
        is required. It is important to separate the two issues.

> The reason it is not the same is as follows:
>
> - With hierarchical mobility agents, the mobile node's home
>   agent can be shielded from having to know about local
>   care-of addresses, as long as it can supply a regional
>   care-of address to the home agent and supply local care-of
>   addresses to the regional mobility agent.
>
        => Agree.

> - With mobile routers, the mobile node "should" be using
>   the prefix of a home address of the mobile router as the
>   prefix by which it forms its own care-of address.  This
>   could be done independently of any sort of hierarchical
>   mobility agent architecture.  In other words, there doesn't
>   have to be any regional mobility agent at all to make
>   a mobile router work.
>
        => But as you say this would work while the MN is located
        at the home network.

> To see this in another way, suppose that the mobile router
> has a fixed Ethernet attached to it.  The nodes on the
> "mobile network" do not run Mobile IPv6.  Why should they
> deal with any advertised care-of addresses from the mobile
> router?
>
        => The mobile router does not need to advertise a COA
        if it is located in the Home network. But when located in
        a foreign network it needs to advertise a COA.
        The reason for advertising a COA is to allow for route
        optimisation. Ie packets sent from the CN directly
        to the MR, and from there to the MN.

> However, this business about mobile routers does bring up
> interesting points.  Suppose the mobile node hooks up to
> a mobile router, and gets a prefix from the advertisement,
> and forms its care-of address.  Packets routed towards that
> care-of address are likely to go through the home agent
> for the mobile router.  The router's home agent will
> encapsulate them.  The mobile router will decapsulate them.
> At this point, the packet should be as issued originally
> by the correspondent node (with a routing header) or
> by the mobile node's home agent (i.e., encapsulated).
>
>
> Now suppose some corrspondent node is sending megabytes of
> data, with each packet having a routing header containing
> the mobile node's care-of address.
>
> We would like for that data not to have to go through the
> home agent for the mobile router.  That means that the
> correspondent node should get information about the care-of
> address for the _mobile router_.  Then, the correspondent node
> could put in a routing header with _two_ care-of addresses.
> The first one would be the care-of address for the mobile
> router, and the second one would be the care-of address
> for the mobile node.
>
        => That's the situation we tried to avoid. In this case the MR
        and the CN have no knowledge of each other.
        In addition for them to know about each other additional
        security requirements are added. It would be simpler
        IMO if the end to end model of MIPv6 is maintained
        by using the MR's COA as an alt-COA for the MN.
        No additions to MIPv6 are required.

> In order to do this directly, the mobile router would need
> some security association with the correspondent node.
> This is one area where this problem shows itself to be much
> different than the hierarchical mobility agent problem.
> For hierarchical mobility agents, there is a natural way
> to set up the security associations.  For the mobile router,
> the same security setup seems unlikely to work.  I didn't
> "map" it out yet, but I reckon some sort of redirect is
> the most likely candidate.  The mobile node can authentically
> "relay" a redirect from the mobile router to the correspondent
> node.  We would have to make some rules about this, but I
> think that what the correspondent node would see would be
> a Binding Update for the care-of address.  This has already
> been specified in another context for smooth handovers.
>
>
> I sure hope we don't have to do this before Mobile IPv6
> completes its Last Call.
>
        => By using the anchor point, there is no need to update
        MIPv6 and the problem becomes independant of MIPv6.
        Isn't that a good thing ?

        Regards,
        Hesham




> "Hesham Soliman (EPA)" wrote:
> >
> > > > > The question is:
> > > > > Is that a problem, if I receive already decapsulated datagrams,
> even
> > > > > if usually I decapsulate them by myself?!
> > > > >
> > > > > Clarifications are welcome.
> > > > >
> > > >         => Your scenario is supported in
> draft-ietf-mobileip-hmipv6-02
> > > >         which will be on the web very soon. I think you'll get the
> > > answer
> > > >         you're looking for there.
> > > >         But as a short answer, no there is no problem because the MN
> > > >         doesn't think that it moved since it is still sending and
> > > receiving
> > > >         packets using its Home address.
> > >
> > > The problem is just this:
> > > I would like the MN to know it moved, so it can update its CNs and its
> > > Home
> > > Agent by itself.
> > >
> >         => I realise that. That's exactly what the draft allows you to
> do.
> >         The MAP option is sent by the Mobile Router (MR), so the MN
> >         knows that it moved and that the MAP acts as a COA for it.
> >         The MN will update the HA and the CNs accordingly with an
> >         alternate-COA as specified in MIPv6. So route optimised
> >         packets will be received by the MAP (MR) and forwarded
> >         to the MN. Every thing happens end to end.
> >         Does that solve your problem ?
> >         Please see the draft for more info.
> >
> >         Regards,
> >         Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 13:39:55 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02427
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 13:39:54 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC10B@standards.nortelnetworks.com>; Tue, 28 Nov 2000 13:13:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 141993 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 13:13:38
          -0500
Received: from cs.rice.edu by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBC109@standards.nortelnetworks.com>;
          Tue, 28 Nov 2000 13:13:38 -0500
Received: from localhost (dbj@localhost) by cs.rice.edu (8.9.0/8.9.0) with
          ESMTP id MAA20532; Tue, 28 Nov 2000 12:30:48 -0600 (CST)
Approved-By:  dbj@CS.RICE.EDU
Message-ID:  <20531.975436248@cs.rice.edu>
Date:         Tue, 28 Nov 2000 12:30:48 -0600
Reply-To: Dave Johnson <dbj@cs.rice.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Dave Johnson <dbj@cs.rice.edu>
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile
              IPv6:draft-ietf-mobileip-ipv6-13.txt
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of "Tue, 28 Nov 2000 08:33:27 PST" 
              <3A23DE57.BB747E82@iprg.nokia.com>

>As indicated in Jean-Michel's original note, ESP is used in tunnel
>mode, so that the entire inner packet is authenticated.  AH takes
>less space, which is why it was originally chosen.
>
>Regards,
>Charlie P.

No, that is incorrect -- I originally chose only AH, based on input
from the working group, since use of ESP was even more complicated
than AH, since ESP only protects the part of the packet below the
ESP header.  Originally, I worded the draft to allow either,
stating only what must be protected (not how to use either AH or
ESP in particular to protect it).  After many requests, however, I
revised it to specify how to use AH, so that at least some minimal
common form of authentication was clearly specified to improve
interoperability.  In particular, only AH in transport mode is
defined in the draft, since it is the minimal (simplest) form of
IPsec that does what we need.  AH/tunnel mode, ESP/transport mode,
and ESP/tunnel mode can all be done, and I made many suggestions
about how they could be specified, in presentations at IETF
meetings and in a presentation at Connectathon in March this year.

                                        Dave


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 13:39:56 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02436
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 13:39:55 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC147@standards.nortelnetworks.com>; Tue, 28 Nov 2000 13:18:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 142072 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 13:18:38
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBC145@standards.nortelnetworks.com>; Tue, 28 Nov 2000 13:18:37
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA17511;
          Tue, 28 Nov 2000 10:35:52 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eASIZnL22031; Tue, 28 Nov 2000 10:35:49
          -0800
X-Virus-Scanned:  Tue, 28 Nov 2000 10:35:49 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdMD4wpe; Tue, 28 Nov 2000
          10:35:33 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <19754.975435023@cs.rice.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A23FAF5.3D5F7977@iprg.nokia.com>
Date:         Tue, 28 Nov 2000 10:35:33 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile
              IPv6:draft-ietf-mobileip-ipv6-13.txt
X-To:         Dave Johnson <dbj@cs.rice.edu>
X-cc:         Jean-Michel COMBES <jeanmichel.combes@rd.francetelecom.fr>,
              "Basavaraj Patil (NTC/Dallas)" <Basavaraj.Patil@nokia.com>,
              Phil Roberts <qa3445@email.mot.com>, David Oran <oran@cisco.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Dave,

Thanks for your note.  I don't wish to make an arbitrary
decision in this matter, so I am trying to gauge working
group consensus.

I agree with you about the need to reach closure soon.

I'm very much hoping someone will make it clear to me about
whether to make the change, because that's a good idea that
represents consensus, or instead to not make the change,
because we don't need to and it's time to get it to IESG.

I'm happy either way.

Regards,
Charlie P.



Dave Johnson wrote:
>
> >Hello folks,
> >
> >Is it really acceptable to strip out all the mandates for authentication
> >methods, and just make a blanket statement that authentication is
> >necessary without saying how to do it?  Perhaps the need for having
> >a common method (for interoperability) is already mandated just by
> >the fact that IPv6 mandates implementation of AH and ESP.  We already
> >don't say how the keys are to be distributed.  Presumably the same
> >method that causes the keys to be distributed would also determine
> >whether AH or ESP is to be used.
>
> Charlie,
>
> That is exactly the way I used to have the draft worded -- for
> exactly the reasons now being discussed.  However, the strong
> consensus that developed seemed to be (at the time) that the draft
> must be specific on how to use IPsec.  And the consensus (again, at
> the time) seemed to be that it was possible to define how to use
> ESP, but relative to AH, use of ESP was quite messy due to the
> differences in what parts of the packet are protected by AH
> vs. ESP.  The thinking was that use of ESP could be added later,
> but that we wanted to get some version to Last Call and Proposed
> Standard ASAP, so the draft only specified use of AH, and only
> specified transport mode, not tunnel mode.  It is certainly
> possible to define all the other combinations, but I think it is
> also still important to reach closure soon on at least some version
> of this and get it through the IESG.
>
>                                         Dave
>
> --
> David B. Johnson, Associate Professor
> of Computer Science and Electrical and Computer Engineering
>
> Department of Computer Science - MS 132    dbj@cs.rice.edu
> Rice University                            http://www.cs.rice.edu/~dbj/
> 6100 Main Street                           Phone: (713) 348-3063
> Houston, Texas 77005-1892 USA              Fax:   (713) 348-5930


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 13:46:22 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04372
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 13:46:22 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC1D4@standards.nortelnetworks.com>; Tue, 28 Nov 2000 13:26:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 142274 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 13:26:56
          -0500
Received: from cs.rice.edu by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBC1C5@standards.nortelnetworks.com>;
          Tue, 28 Nov 2000 13:26:51 -0500
Received: from localhost (dbj@localhost) by cs.rice.edu (8.9.0/8.9.0) with
          ESMTP id MAA21022; Tue, 28 Nov 2000 12:43:21 -0600 (CST)
Approved-By:  dbj@CS.RICE.EDU
Message-ID:  <21021.975437001@cs.rice.edu>
Date:         Tue, 28 Nov 2000 12:43:21 -0600
Reply-To: Dave Johnson <dbj@cs.rice.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Dave Johnson <dbj@cs.rice.edu>
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile
              IPv6:draft-ietf-mobileip-ipv6-13.txt
X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
X-cc:         Jean-Michel COMBES <jeanmichel.combes@rd.francetelecom.fr>,
              "Basavaraj Patil (NTC/Dallas)" <Basavaraj.Patil@nokia.com>,
              Phil Roberts <qa3445@email.mot.com>, David Oran <oran@cisco.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of "Tue, 28 Nov 2000 10:35:33 PST" 
              <3A23FAF5.3D5F7977@iprg.nokia.com>

Charlie,

As noted in my note :-), the working group consensus has already
been gauged in the past on exactly this issue that you are raising
again now, which is exactly why I previously changed the draft from
the way I had it to the way it is now.  The question you are
raising is whether we should reverse that consensus and go back to
the way I had the draft before.  I belive the consensus at the time
was to be specific about how to use IPsec, and the consensus I see
coming in now I think is saying the same thing.

                                        Dave


>Hello Dave,
>
>Thanks for your note.  I don't wish to make an arbitrary
>decision in this matter, so I am trying to gauge working
>group consensus.
>
>I agree with you about the need to reach closure soon.
>
>I'm very much hoping someone will make it clear to me about
>whether to make the change, because that's a good idea that
>represents consensus, or instead to not make the change,
>because we don't need to and it's time to get it to IESG.
>
>I'm happy either way.
>
>Regards,
>Charlie P.
>
>
>
>Dave Johnson wrote:
>>
>> >Hello folks,
>> >
>> >Is it really acceptable to strip out all the mandates for authenticatio
n
>> >methods, and just make a blanket statement that authentication is
>> >necessary without saying how to do it?  Perhaps the need for having
>> >a common method (for interoperability) is already mandated just by
>> >the fact that IPv6 mandates implementation of AH and ESP.  We already
>> >don't say how the keys are to be distributed.  Presumably the same
>> >method that causes the keys to be distributed would also determine
>> >whether AH or ESP is to be used.
>>
>> Charlie,
>>
>> That is exactly the way I used to have the draft worded -- for
>> exactly the reasons now being discussed.  However, the strong
>> consensus that developed seemed to be (at the time) that the draft
>> must be specific on how to use IPsec.  And the consensus (again, at
>> the time) seemed to be that it was possible to define how to use
>> ESP, but relative to AH, use of ESP was quite messy due to the
>> differences in what parts of the packet are protected by AH
>> vs. ESP.  The thinking was that use of ESP could be added later,
>> but that we wanted to get some version to Last Call and Proposed
>> Standard ASAP, so the draft only specified use of AH, and only
>> specified transport mode, not tunnel mode.  It is certainly
>> possible to define all the other combinations, but I think it is
>> also still important to reach closure soon on at least some version
>> of this and get it through the IESG.
>>
>>                                         Dave
>>
>> --
>> David B. Johnson, Associate Professor
>> of Computer Science and Electrical and Computer Engineering
>>
>> Department of Computer Science - MS 132    dbj@cs.rice.edu
>> Rice University                            http://www.cs.rice.edu/~dbj/
>> 6100 Main Street                           Phone: (713) 348-3063
>> Houston, Texas 77005-1892 USA              Fax:   (713) 348-5930


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 13:58:00 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07770
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 13:57:59 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC22D@standards.nortelnetworks.com>; Tue, 28 Nov 2000 13:38:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 142395 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 13:38:50
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:64323) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBC22B@standards.nortelnetworks.com>; Tue, 28 Nov 2000
          13:38:49 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id FAA29114 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Nov 2000 05:52:30
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id FAA05120 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Nov 2000 05:55:22
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD6T66>; Wed, 29 Nov 2000 05:55:40 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613EAD@eaubrnt018.epa.ericsson.se>
Date:         Wed, 29 Nov 2000 05:55:30 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile IPv6:draft-ietf-mobileip-ipv
              6-13.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I thought the main goal was to go to last call ASAP.
So if there is no problem with version 13 do we really
need this new change ?
As Dave says below this may be more complex, so it
might be worth saving this for a bis.

I'd like to see MIPv6 become an RFC one day ;)

Hesham



> -----Original Message-----
> From: Dave Johnson [SMTP:dbj@cs.rice.edu]
> Sent: Wednesday, 29 November 2000 5:31
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: [MOBILE-IP] WG Last Call: Mobile
> IPv6:draft-ietf-mobileip-ipv6-13.txt
>
> >As indicated in Jean-Michel's original note, ESP is used in tunnel
> >mode, so that the entire inner packet is authenticated.  AH takes
> >less space, which is why it was originally chosen.
> >
> >Regards,
> >Charlie P.
>
> No, that is incorrect -- I originally chose only AH, based on input
> from the working group, since use of ESP was even more complicated
> than AH, since ESP only protects the part of the packet below the
> ESP header.  Originally, I worded the draft to allow either,
> stating only what must be protected (not how to use either AH or
> ESP in particular to protect it).  After many requests, however, I
> revised it to specify how to use AH, so that at least some minimal
> common form of authentication was clearly specified to improve
> interoperability.  In particular, only AH in transport mode is
> defined in the draft, since it is the minimal (simplest) form of
> IPsec that does what we need.  AH/tunnel mode, ESP/transport mode,
> and ESP/tunnel mode can all be done, and I made many suggestions
> about how they could be specified, in presentations at IETF
> meetings and in a presentation at Connectathon in March this year.
>
>                                         Dave


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 14:15:10 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12627
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 14:15:09 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC2A6@standards.nortelnetworks.com>; Tue, 28 Nov 2000 13:55:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 142559 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 13:55:58
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBC2A4@standards.nortelnetworks.com>; Tue, 28 Nov 2000 13:55:57
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA22824;
          Tue, 28 Nov 2000 11:13:12 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eASJD8O11563; Tue, 28 Nov 2000 11:13:08
          -0800
X-Virus-Scanned:  Tue, 28 Nov 2000 11:13:08 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdeDtcRg; Tue, 28 Nov 2000
          11:10:11 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <4B6BC00CD15FD2119E5F0008C7A419A50C613EAC@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A240314.7C75BB46@iprg.nokia.com>
Date:         Tue, 28 Nov 2000 11:10:12 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] IPv6 mobile routers vs. regional mobility agents
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Hesham,

Thanks for taking the time to read through these long e-mails.

> > I think there's another way to look at this problem of
> > mobile routers that offers a "better" solution.  It isn't
> > the same problem as has been discussed in connection with
> > hiearchical mobility agents.  It should not be solved by
> > techniques associated with hierarchical mobility agents.
> > Nor anchor points, if I may use that terminology.  A mobile
> > router should not necessarily be considered an anchor point
> > or a regional mobility agent.
> >
>         => First I'd like to clarify the situation where an anchor
>         point is needed. Consider a Personal Area Network
>         (PAN). When that network attaches via one or more
>         routers on that PAN to a foreign network, it may not be
>         possible to obtain a topologically correct preftx to allow
>         this PAN to use topologically correct addresses.

Maybe you're defining something other than a router.
If the PAN router is a router, it should make router
advertisements.  The router advertisements should allow
nodes to attach to its network(s).  These advertisements
could be used by mobile nodes that want to attach to the
network over which the PAN router's advertisements are
being transmitted.  I don't see that this should be
different than normal.

>         So this is the problem I assumed we were looking at
>         in the previous thread. So the case is : the MN has
>         physically moved but not topologically. It needs to map
>         the physical movement into a topological one.
>         No hierarchy is needed here. Just a topologically correct
>         COA. It just happens that we can use an anchor point's
>         address for that purpose. No hierarchy of anchor points
>         is required. It is important to separate the two issues.

Granted that it's important to separate the issues.  But your
claim that the mobile nodes have to detect the movements of
the mobile router that is serving them is, I think, suspect.
It amounts to a transfer of responsibility from the mobile
router to the nodes it is serving.  The disharmony of this
approach is particularly evident when the nodes attached to
the mobile router are NOT themselves mobile nodes.


> > - With mobile routers, the mobile node "should" be using
> >   the prefix of a home address of the mobile router as the
> >   prefix by which it forms its own care-of address.  This
> >   could be done independently of any sort of hierarchical
> >   mobility agent architecture.  In other words, there doesn't
> >   have to be any regional mobility agent at all to make
> >   a mobile router work.
> >
>         => But as you say this would work while the MN is located
>         at the home network.

I thought it would work no matter where the MN was located.
In this discussion, we have to be careful to distinguish between
the MN's home network, and the mobile router's home network.
It is likely that there are two home agents involved.

> > To see this in another way, suppose that the mobile router
> > has a fixed Ethernet attached to it.  The nodes on the
> > "mobile network" do not run Mobile IPv6.  Why should they
> > deal with any advertised care-of addresses from the mobile
> > router?
> >
>         => The mobile router does not need to advertise a COA
>         if it is located in the Home network. But when located in
>         a foreign network it needs to advertise a COA.
>         The reason for advertising a COA is to allow for route
>         optimisation. Ie packets sent from the CN directly
>         to the MR, and from there to the MN.

This is what I am trying to say is wrong.  I also claim that
it's a good illustration about how one might fashion a new
sort of "redirect" message to allow such fixed nodes to do the
right sort of "route optimization" that you allude to.

            .........

> > We would like for that data not to have to go through the
> > home agent for the mobile router.  That means that the
> > correspondent node should get information about the care-of
> > address for the _mobile router_.  Then, the correspondent node
> > could put in a routing header with _two_ care-of addresses.
> > The first one would be the care-of address for the mobile
> > router, and the second one would be the care-of address
> > for the mobile node.
> >
>         => That's the situation we tried to avoid. In this case the MR
>         and the CN have no knowledge of each other.
>         In addition for them to know about each other additional
>         security requirements are added. It would be simpler
>         IMO if the end to end model of MIPv6 is maintained
>         by using the MR's COA as an alt-COA for the MN.
>         No additions to MIPv6 are required.

I think that your approach is simpler in some cases if you
disregard the security implications and the general routing
model of Mobile IPv6.  I also point out again that it's not
the endpoint that's moving, and in fact it's not the endpoint
that should be considered to even have a care-of address.
Things that live on their home network and don't move don't
have care-of addresses.  Yet, with your scheme, they would.


> > In order to do this directly, the mobile router would need
> > some security association with the correspondent node.
> > This is one area where this problem shows itself to be much
> > different than the hierarchical mobility agent problem.
> > For hierarchical mobility agents, there is a natural way
> > to set up the security associations.  For the mobile router,
> > the same security setup seems unlikely to work.  I didn't
> > "map" it out yet, but I reckon some sort of redirect is
> > the most likely candidate.  The mobile node can authentically
> > "relay" a redirect from the mobile router to the correspondent
> > node.  We would have to make some rules about this, but I
> > think that what the correspondent node would see would be
> > a Binding Update for the care-of address.  This has already
> > been specified in another context for smooth handovers.
> >
> >
> > I sure hope we don't have to do this before Mobile IPv6
> > completes its Last Call.
> >
>         => By using the anchor point, there is no need to update
>         MIPv6 and the problem becomes independant of MIPv6.
>         Isn't that a good thing ?

Paraphrasing, we should make things as simple as possible,
but not any simpler.

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 14:29:52 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16822
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 14:29:51 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC30F@standards.nortelnetworks.com>; Tue, 28 Nov 2000 14:10:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 142697 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 14:10:38
          -0500
Received: from panther.Gsu.EDU by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBC30D@standards.nortelnetworks.com>; Tue, 28 Nov 2000 14:10:38
          -0500
Received: from localhost by panther.Gsu.EDU (8.9.3/8.9.3-GSU-MOD-NOLOVE) with
          SMTP id OAA20529; Tue, 28 Nov 2000 14:27:38 -0500 (EST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved-By:  Hrishi Talwar <gs01hst@PANTHER.GSU.EDU>
Message-ID:  <Pine.GSO.3.95.1001128142725.20379A-100000@panther.Gsu.EDU>
Date:         Tue, 28 Nov 2000 14:27:38 -0500
Reply-To: Hrishi Talwar <gs01hst@panther.Gsu.EDU>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Hrishi Talwar <gs01hst@panther.Gsu.EDU>
Subject:      Re: [MOBILE-IP] IPv6 mobile routers vs. regional mobility agents
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <3A240314.7C75BB46@iprg.nokia.com>

unsubscribe

On Tue, 28 Nov 2000, Charles E. Perkins wrote:

> Date: Tue, 28 Nov 2000 11:10:12 -0800
> From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] IPv6 mobile routers vs. regional mobility agents
>
> Hello Hesham,
>
> Thanks for taking the time to read through these long e-mails.
>
> > > I think there's another way to look at this problem of
> > > mobile routers that offers a "better" solution.  It isn't
> > > the same problem as has been discussed in connection with
> > > hiearchical mobility agents.  It should not be solved by
> > > techniques associated with hierarchical mobility agents.
> > > Nor anchor points, if I may use that terminology.  A mobile
> > > router should not necessarily be considered an anchor point
> > > or a regional mobility agent.
> > >
> >         => First I'd like to clarify the situation where an anchor
> >         point is needed. Consider a Personal Area Network
> >         (PAN). When that network attaches via one or more
> >         routers on that PAN to a foreign network, it may not be
> >         possible to obtain a topologically correct preftx to allow
> >         this PAN to use topologically correct addresses.
>
> Maybe you're defining something other than a router.
> If the PAN router is a router, it should make router
> advertisements.  The router advertisements should allow
> nodes to attach to its network(s).  These advertisements
> could be used by mobile nodes that want to attach to the
> network over which the PAN router's advertisements are
> being transmitted.  I don't see that this should be
> different than normal.
>
> >         So this is the problem I assumed we were looking at
> >         in the previous thread. So the case is : the MN has
> >         physically moved but not topologically. It needs to map
> >         the physical movement into a topological one.
> >         No hierarchy is needed here. Just a topologically correct
> >         COA. It just happens that we can use an anchor point's
> >         address for that purpose. No hierarchy of anchor points
> >         is required. It is important to separate the two issues.
>
> Granted that it's important to separate the issues.  But your
> claim that the mobile nodes have to detect the movements of
> the mobile router that is serving them is, I think, suspect.
> It amounts to a transfer of responsibility from the mobile
> router to the nodes it is serving.  The disharmony of this
> approach is particularly evident when the nodes attached to
> the mobile router are NOT themselves mobile nodes.
>
>
> > > - With mobile routers, the mobile node "should" be using
> > >   the prefix of a home address of the mobile router as the
> > >   prefix by which it forms its own care-of address.  This
> > >   could be done independently of any sort of hierarchical
> > >   mobility agent architecture.  In other words, there doesn't
> > >   have to be any regional mobility agent at all to make
> > >   a mobile router work.
> > >
> >         => But as you say this would work while the MN is located
> >         at the home network.
>
> I thought it would work no matter where the MN was located.
> In this discussion, we have to be careful to distinguish between
> the MN's home network, and the mobile router's home network.
> It is likely that there are two home agents involved.
>
> > > To see this in another way, suppose that the mobile router
> > > has a fixed Ethernet attached to it.  The nodes on the
> > > "mobile network" do not run Mobile IPv6.  Why should they
> > > deal with any advertised care-of addresses from the mobile
> > > router?
> > >
> >         => The mobile router does not need to advertise a COA
> >         if it is located in the Home network. But when located in
> >         a foreign network it needs to advertise a COA.
> >         The reason for advertising a COA is to allow for route
> >         optimisation. Ie packets sent from the CN directly
> >         to the MR, and from there to the MN.
>
> This is what I am trying to say is wrong.  I also claim that
> it's a good illustration about how one might fashion a new
> sort of "redirect" message to allow such fixed nodes to do the
> right sort of "route optimization" that you allude to.
>
>             .........
>
> > > We would like for that data not to have to go through the
> > > home agent for the mobile router.  That means that the
> > > correspondent node should get information about the care-of
> > > address for the _mobile router_.  Then, the correspondent node
> > > could put in a routing header with _two_ care-of addresses.
> > > The first one would be the care-of address for the mobile
> > > router, and the second one would be the care-of address
> > > for the mobile node.
> > >
> >         => That's the situation we tried to avoid. In this case the MR
> >         and the CN have no knowledge of each other.
> >         In addition for them to know about each other additional
> >         security requirements are added. It would be simpler
> >         IMO if the end to end model of MIPv6 is maintained
> >         by using the MR's COA as an alt-COA for the MN.
> >         No additions to MIPv6 are required.
>
> I think that your approach is simpler in some cases if you
> disregard the security implications and the general routing
> model of Mobile IPv6.  I also point out again that it's not
> the endpoint that's moving, and in fact it's not the endpoint
> that should be considered to even have a care-of address.
> Things that live on their home network and don't move don't
> have care-of addresses.  Yet, with your scheme, they would.
>
>
> > > In order to do this directly, the mobile router would need
> > > some security association with the correspondent node.
> > > This is one area where this problem shows itself to be much
> > > different than the hierarchical mobility agent problem.
> > > For hierarchical mobility agents, there is a natural way
> > > to set up the security associations.  For the mobile router,
> > > the same security setup seems unlikely to work.  I didn't
> > > "map" it out yet, but I reckon some sort of redirect is
> > > the most likely candidate.  The mobile node can authentically
> > > "relay" a redirect from the mobile router to the correspondent
> > > node.  We would have to make some rules about this, but I
> > > think that what the correspondent node would see would be
> > > a Binding Update for the care-of address.  This has already
> > > been specified in another context for smooth handovers.
> > >
> > >
> > > I sure hope we don't have to do this before Mobile IPv6
> > > completes its Last Call.
> > >
> >         => By using the anchor point, there is no need to update
> >         MIPv6 and the problem becomes independant of MIPv6.
> >         Isn't that a good thing ?
>
> Paraphrasing, we should make things as simple as possible,
> but not any simpler.
>
> Regards,
> Charlie P.
>

*********************************************************
Computers aren't intelligent, they only think they are. *
*********************************************************
***************************
Hrishi S Talwar           *
2220B Lindmont Circle NE  *
Atlanta, GA 30324         *
Ph. 404-949-9706          *
***************************


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 15:03:14 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26738
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 15:03:14 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC373@standards.nortelnetworks.com>; Tue, 28 Nov 2000 14:44:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 142832 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 14:44:12
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBC371@standards.nortelnetworks.com>; Tue, 28 Nov 2000 14:44:11
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eASK1I404318; Tue, 28 Nov 2000 21:01:18 +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 VAA02477; Tue, 28 Nov 2000 21:01:17 +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.9.3/8.9.3) with
          ESMTP id VAA03901; Tue, 28 Nov 2000 21:01:19 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011282001.VAA03901@givry.rennes.enst-bretagne.fr>
Date:         Tue, 28 Nov 2000 21:01:19 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile
              IPv6:draft-ietf-mobileip-ipv6-13.txt
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Tue, 28 Nov 2000 07:53:15 PST. 
              <3A23D4EB.CC119E99@iprg.nokia.com>

 In your previous mail you wrote:

   Is it really acceptable to strip out all the mandates for authentication
   methods, and just make a blanket statement that authentication is
   necessary without saying how to do it?

=> this will just make the specifications not usable.
IMHO the specs should describe a solution (AH which is known to work)
and let others (ESP, tunnel stuff) for further studies.
We should go to IESG ASAP!

   Perhaps the need for having
   a common method (for interoperability) is already mandated just by
   the fact that IPv6 mandates implementation of AH and ESP.  We already
   don't say how the keys are to be distributed.

=> this is not true, there are some clever statements about how to use IKE
in order to establish security associations (then keys).

   Presumably the same method that causes the keys to be distributed
   would also determine whether AH or ESP is to be used.

=> this will work if (quote IPsec) IKE is used as a policy enforcement
protocol and not a policy negociation protocol but this should give
major interoperability problems...

   If that can be represented as working-group consensus, I will go about
   the process of making a new draft revision for Mobile IPv6.

=> I don't believe to add again six months to the date for mobile IPv6
avaibility is a good move (nor someone will get a consensus in favor
of this :-).

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 15:11:44 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28944
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 15:11:43 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC3B3@standards.nortelnetworks.com>; Tue, 28 Nov 2000 14:52:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 142918 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 14:52:29
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:65013) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBC3B1@standards.nortelnetworks.com>; Tue, 28 Nov 2000
          14:52:28 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id HAA01090; Wed,
          29 Nov 2000 07:06:13 +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id HAA10863; Wed, 29
          Nov 2000 07:09:06 +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD6VPC>; Wed, 29 Nov 2000 07:09:23 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613EAE@eaubrnt018.epa.ericsson.se>
Date:         Wed, 29 Nov 2000 07:09:12 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] IPv6 mobile routers vs. regional mobility agents
X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hello Charlie

> Thanks for taking the time to read through these long e-mails.
>
        You're welcome, I can't resist an interesting discussion :)

> > > I think there's another way to look at this problem of
> > > mobile routers that offers a "better" solution.  It isn't
> > > the same problem as has been discussed in connection with
> > > hiearchical mobility agents.  It should not be solved by
> > > techniques associated with hierarchical mobility agents.
> > > Nor anchor points, if I may use that terminology.  A mobile
> > > router should not necessarily be considered an anchor point
> > > or a regional mobility agent.
> > >
> >         => First I'd like to clarify the situation where an anchor
> >         point is needed. Consider a Personal Area Network
> >         (PAN). When that network attaches via one or more
> >         routers on that PAN to a foreign network, it may not be
> >         possible to obtain a topologically correct preftx to allow
> >         this PAN to use topologically correct addresses.
>
> Maybe you're defining something other than a router.
> If the PAN router is a router, it should make router
> advertisements.  The router advertisements should allow
> nodes to attach to its network(s).  These advertisements
> could be used by mobile nodes that want to attach to the
> network over which the PAN router's advertisements are
> being transmitted.  I don't see that this should be
> different than normal.
>
        => I suspect we're talking about 2 different scenarios.
        I'm talking about a MR that has a home prefix.
        Sure it will send a router advertisement, but that will
        contain the Home prefix, unless of course it can get a
        topologically correct prefix from the visited network .
        In the latter case it wouldn't be different than normal,
        but I'm tryinto address the case where the MR gets
        an address on one interface while maintaining the Home
        prefix on the other interface.

> >         So this is the problem I assumed we were looking at
> >         in the previous thread. So the case is : the MN has
> >         physically moved but not topologically. It needs to map
> >         the physical movement into a topological one.
> >         No hierarchy is needed here. Just a topologically correct
> >         COA. It just happens that we can use an anchor point's
> >         address for that purpose. No hierarchy of anchor points
> >         is required. It is important to separate the two issues.
>
> Granted that it's important to separate the issues.  But your
> claim that the mobile nodes have to detect the movements of
> the mobile router that is serving them is, I think, suspect.
> It amounts to a transfer of responsibility from the mobile
> router to the nodes it is serving.  The disharmony of this
> approach is particularly evident when the nodes attached to
> the mobile router are NOT themselves mobile nodes.
>
        => I'm not sure I understand where the disharmony is.
        If the MNs (attached to the MR) can not receive a topologically
        correct router advertisement, they can't tell that they moved
        (if they were actually MNs). If they were not MNs, then something
        else is needed to route their packets from the Home prefix.
        Please note that I'm assuming that they are MNs (ie.
        have a MN implementation). For the other scenario
        please see my comments at the end of the mail.

> > > - With mobile routers, the mobile node "should" be using
> > >   the prefix of a home address of the mobile router as the
> > >   prefix by which it forms its own care-of address.  This
> > >   could be done independently of any sort of hierarchical
> > >   mobility agent architecture.  In other words, there doesn't
> > >   have to be any regional mobility agent at all to make
> > >   a mobile router work.
> > >
> >         => But as you say this would work while the MN is located
> >         at the home network.
>
> I thought it would work no matter where the MN was located.
> In this discussion, we have to be careful to distinguish between
> the MN's home network, and the mobile router's home network.
> It is likely that there are two home agents involved.
>
        => Agreed. If there are 2 HAs, then the problem is more
        complex. But if the MR advertises its COA and can act
        as an alt-COA for the MNs attached, then packets will
        always be routed to the MN in an optimal way. Even if there
        are 2 HAs

> > > To see this in another way, suppose that the mobile router
> > > has a fixed Ethernet attached to it.  The nodes on the
> > > "mobile network" do not run Mobile IPv6.  Why should they
> > > deal with any advertised care-of addresses from the mobile
> > > router?
> > >
> >         => The mobile router does not need to advertise a COA
> >         if it is located in the Home network. But when located in
> >         a foreign network it needs to advertise a COA.
> >         The reason for advertising a COA is to allow for route
> >         optimisation. Ie packets sent from the CN directly
> >         to the MR, and from there to the MN.
>
> This is what I am trying to say is wrong.  I also claim that
> it's a good illustration about how one might fashion a new
> sort of "redirect" message to allow such fixed nodes to do the
> right sort of "route optimization" that you allude to.
>
        => Why is this wrong ? If the prefix (on the PAN) is not
        topologically correct, then packets addressed to the nodes
        attached to the MR will not be delivered. So unless, a COA
        is given to these nodes, how can they receive packets ?
>             .........
>
> > > We would like for that data not to have to go through the
> > > home agent for the mobile router.  That means that the
> > > correspondent node should get information about the care-of
> > > address for the _mobile router_.  Then, the correspondent node
> > > could put in a routing header with _two_ care-of addresses.
> > > The first one would be the care-of address for the mobile
> > > router, and the second one would be the care-of address
> > > for the mobile node.
> > >
> >         => That's the situation we tried to avoid. In this case the MR
> >         and the CN have no knowledge of each other.
> >         In addition for them to know about each other additional
> >         security requirements are added. It would be simpler
> >         IMO if the end to end model of MIPv6 is maintained
> >         by using the MR's COA as an alt-COA for the MN.
> >         No additions to MIPv6 are required.
>
> I think that your approach is simpler in some cases if you
> disregard the security implications and the general routing
> model of Mobile IPv6.
>
        => The approach does not introduce any additional security
        requirements. Please elaborate on where the security
        problems may arise. Regarding the routing, this approach
        is identical to HMIPv6 and is equivalent to Reg in MIPv4.
        The whole point is to keep the aggregate routing in the
        backbone unchanged.

> I also point out again that it's not
> the endpoint that's moving, and in fact it's not the endpoint
> that should be considered to even have a care-of address.
> Things that live on their home network and don't move don't
> have care-of addresses.  Yet, with your scheme, they would.
>
        => Physical movement is not the only problem that I'm trying to
        solve. Consider the case where a MR which has a Home prefix
        suddenly shows up in a house network and starts advertising
        its Home prefix (which is not topologically correct). If I
understand
        you correctly you're saying that this MR is responsible for making
        sure that packets addressed to the devices attached to it
        (who just heard a new prefix) get there. What I'm saying is
        that this can be done by letting these devices know that this
        prefix is not topologically correct and giving them a topologically
        correct COA. But what you're saying is that the MR needs to
        make sure it can do this without informing those devices.
        Both can work. But the approach I mentioned will work today,
        and the one you mention needs a bit more work and new
        releationships between the MR and the CNs, which btw it
        doesn't know.

        The approach I mentioned will not work if the devices do not
        have a MN implementation. In this case I'd like to refer you
        to draft-ernst-mobileip-v6-network, which addresses that
        scenario and provides some interesting ideas.

        Regards,
        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 15:19:18 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00992
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 15:19:17 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC3DA@standards.nortelnetworks.com>; Tue, 28 Nov 2000 14:55:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 142967 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 14:55:39
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBC3D7@standards.nortelnetworks.com>; Tue, 28 Nov 2000 14:55:38
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eASKCj425065; Tue, 28 Nov 2000 21:12: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 VAA02945; Tue, 28 Nov 2000 21:12: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.9.3/8.9.3) with
          ESMTP id VAA03988; Tue, 28 Nov 2000 21:12:46 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011282012.VAA03988@givry.rennes.enst-bretagne.fr>
Date:         Tue, 28 Nov 2000 21:12:46 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile IPv6:draft-ietf-mobileip-ipv
              6-13.txt
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Wed, 29 Nov 2000 03:17:07 +1100. 
              <4B6BC00CD15FD2119E5F0008C7A419A50C613EA6@eaubrnt018.epa.ericsson.se>

 In your previous mail you wrote:

   If I understand you correctly, you're saying we should allow
   either ESP or AH. And that since IPv6 supports both
   then there shouldn't be an interoperability problem.

=> it is more by compromise than for interoperability (:-)!

   To be able to for an opinion I need to ask a couple of questions
   about IPsec.
   I thought that ESP would authenticate everything below the ESP
   header and not before it ? Is that correct ?

=> yes that is (and you do know this :-).

   If that's not correct then why was AH chosen in the first place ?

=> just because that is correct.

   If ESP can authenticate the entire packet then I don't see
   a problem with your suggestion, but I'd like to know why
   AH was chosen over ESP.

=> the home address should be before the IPsec header(s) because:
 - this works with any IPsec implementation on the receiving side
   (don't forget the receiving side is the general one then the complexity
    if you can't avoid it should be on the sending side)
 - this is (very) firewall friendly. I don't like firewalls (I prefer IPsec)
   but I believe we may not in the same time propose something which
   bypass ingress-filtering (the home address option) and make it totally
   firewall unfriendly (ie. suggest to hide it behind an ESP).
I'd like to get the firewall people opinion at the IETF last call...

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 15:26:40 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03105
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 15:26:39 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC448@standards.nortelnetworks.com>; Tue, 28 Nov 2000 15:07:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 143121 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 15:07:31
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBC446@standards.nortelnetworks.com>; Tue, 28 Nov 2000 15:07:31
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eASKOd425571; Tue, 28 Nov 2000 21:24:39 +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 VAA03373; Tue, 28 Nov 2000 21:24:37 +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.9.3/8.9.3) with
          ESMTP id VAA04072; Tue, 28 Nov 2000 21:24:39 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011282024.VAA04072@givry.rennes.enst-bretagne.fr>
Date:         Tue, 28 Nov 2000 21:24:39 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile
              IPv6:draft-ietf-mobileip-ipv6-13.txt
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Tue, 28 Nov 2000 08:33:27 PST. 
              <3A23DE57.BB747E82@iprg.nokia.com>

 In your previous mail you wrote:

   As indicated in Jean-Michel's original note, ESP is used in tunnel
   mode, so that the entire inner packet is authenticated.  AH takes
   less space, which is why it was originally chosen.

=> and as most IPsec implementations check the (outer) source address
then ESP in tunnel mode doesn't work (even if RFC 2401 5.1.2.1 3- NOTE
suggests explicitely this should not cause a problem). The AH solution
is far more easier for inbound IPsec processing, this is enough to
retain it for first specs.

Francis.Dupont@enst-bretagne.fr

PS: the problem with ESP should be addresses as soon as possible because
if the current proposal for mobility is more efficient than tunnelling,
if there are already tunnels it has a large and unjustified overhead...


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 16:09:40 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15597
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 16:09:40 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC54E@standards.nortelnetworks.com>; Tue, 28 Nov 2000 15:50:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 143445 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 15:50:26
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBC54C@standards.nortelnetworks.com>; Tue, 28 Nov 2000 15:50:25
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eASL7V419806; Tue, 28 Nov 2000 22:07:31 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr
          [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with
          ESMTP id WAA04975; Tue, 28 Nov 2000 22:07:30 +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.9.3/8.9.3) with
          ESMTP id WAA04348; Tue, 28 Nov 2000 22:07:32 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011282107.WAA04348@givry.rennes.enst-bretagne.fr>
Date:         Tue, 28 Nov 2000 22:07:32 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] IPv6 mobile routers vs. regional mobility agents
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Tue, 28 Nov 2000 09:55:02 PST. 
              <3A23F176.3A047674@iprg.nokia.com>

 In your previous mail you wrote:

   I think there's another way to look at this problem of
   mobile routers that offers a "better" solution.

=> mobile routers are an interesting problem (there are many
examples of them, for instance modern planes are LANs with
mobile border routers). After some (private) mail exchanges
with Thierry Ernst (the author of a mobile IPv6 draft) I
believe this will be a place where mobility will interact
with IPsec tunnels, for instance if you use a bidirectional
ESP tunnel between the mobile router and the home agent.

   A mobile router should not necessarily be considered an anchor
   point or a regional mobility agent.

=> I agree, in many cases the nodes behind the mobile router don't
know something is moving. This is both a nice thing and a source
of problems...

   To see this in another way, suppose that the mobile router
   has a fixed Ethernet attached to it.  The nodes on the
   "mobile network" do not run Mobile IPv6.  Why should they
   deal with any advertised care-of addresses from the mobile
   router?

=> exactly!

   In order to do this directly, the mobile router would need
   some security association with the correspondent node.

=> there are false ideas about what is the security issue.
In fact for an ordinary correspondent node there is nothing really
different than for mobile IPv6. You can consider that in place
of a request for a binding for a prefix the mobile router can
send on demand a request per nodes behind him...
 This is a bit different for the home agent because you would not
like to deal with mobile nodes and mobile routers the same way,
but this is not an IPsec issue, only an authorization issue
(don't forget that IPsec gives a strong authentication then
the question is do you or don't you permit this router to register
a whole prefix?)

   I sure hope we don't have to do this before Mobile IPv6
   completes its Last Call.

=> when will be able to use Mobile IPv6 as a signaling protocol
for moving an end of a IPsec tunnel the mobile router problem
will have a very simple solution. The only things we need are:
 - a Mobile IPv6 published as an RFC
 - same * <very large prime number>
 - a real status for IPsec tunnels
 - a fix for the outer source address check issue
 - a standard and secure way to update the (outer) address of
   a IPsec tunnel end-point (new PF_KEY message?)

Thanks

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 16:16:58 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18908
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 16:16:58 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC58E@standards.nortelnetworks.com>; Tue, 28 Nov 2000 15:57:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 143531 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 15:57:31
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBC58C@standards.nortelnetworks.com>; Tue, 28 Nov 2000 15:57:31
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eASLEg432229; Tue, 28 Nov 2000 22:14:42 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr
          [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with
          ESMTP id WAA05222; Tue, 28 Nov 2000 22:14:42 +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.9.3/8.9.3) with
          ESMTP id WAA04397; Tue, 28 Nov 2000 22:14:44 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011282114.WAA04397@givry.rennes.enst-bretagne.fr>
Date:         Tue, 28 Nov 2000 22:14:44 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile IPv6:draft-ietf-mobileip-ipv
              6-13.txt
X-To:         Richard Draves <richdr@microsoft.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Tue, 28 Nov 2000 10:07:47 PST. 
              <7695E2F6903F7A41961F8CF888D87EA801469885@red-msg-06.redmond.corp.microsoft.com>

 In your previous mail you wrote:

   I think the draft needs to be quite clear about the allowable packet header
   arrangements and what addresses in which headers get used for security
   policy checks. Being wishy-washy about what the packets can look like will
   be very bad for interoperability.

=> I agree.

   Yes, IKE negotiation or manual configuration could choose between the use of
   AH or ESP, besides choosing the specific transforms.

=> my concern is in some cases policies won't be compatible and IKE
(or manual configuration) won't be able to detect this, ie. it will fail
and we shall have to read kilobytes of logs in order to understand
what happened.
IMHO we should have a written down reasonable default, with the current
(previous?) proposal it should be AH transport mode for everything between
MN and CN (ie. any protocol (and port)).

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 16:24:08 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21856
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 16:24:08 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC5BC@standards.nortelnetworks.com>; Tue, 28 Nov 2000 16:00:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 143590 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 16:00:48
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBC5B8@standards.nortelnetworks.com>; Tue, 28 Nov 2000 16:00:48
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eASLI0412076; Tue, 28 Nov 2000 22:18:00 +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 WAA05355; Tue, 28 Nov 2000 22:17:59 +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.9.3/8.9.3) with
          ESMTP id WAA04431; Tue, 28 Nov 2000 22:18:01 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011282118.WAA04431@givry.rennes.enst-bretagne.fr>
Date:         Tue, 28 Nov 2000 22:18:01 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile
              IPv6:draft-ietf-mobileip-ipv6-13.txt
X-To:         Dave Johnson <dbj@cs.rice.edu>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Tue, 28 Nov 2000 12:10:23 CST. 
              <19754.975435023@cs.rice.edu>

 In your previous mail you wrote:

   That is exactly the way I used to have the draft worded -- for
   exactly the reasons now being discussed.  However, the strong
   consensus that developed seemed to be (at the time) that the draft
   must be specific on how to use IPsec.  And the consensus (again, at
   the time) seemed to be that it was possible to define how to use
   ESP, but relative to AH, use of ESP was quite messy due to the
   differences in what parts of the packet are protected by AH
   vs. ESP.  The thinking was that use of ESP could be added later,
   but that we wanted to get some version to Last Call and Proposed
   Standard ASAP, so the draft only specified use of AH, and only
   specified transport mode, not tunnel mode.  It is certainly
   possible to define all the other combinations, but I think it is
   also still important to reach closure soon on at least some version
   of this and get it through the IESG.

=> I couldn't say that in a better way!

Thanks!!!

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Nov 28 17:30:23 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20725
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Nov 2000 17:30:23 -0500 (EST)
Received: from standards (47.234.32.16:4552) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC676@standards.nortelnetworks.com>; Tue, 28 Nov 2000 17:11:18 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 143838 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 17:11:18
          -0500
Received: from spsystems.net by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBC674@standards.nortelnetworks.com>;
          Tue, 28 Nov 2000 17:11:17 -0500
Received: (from henry@localhost) by spsystems.net (8.9.3/8.9.3) id RAA10171;
          Tue, 28 Nov 2000 17:28:16 -0500 (EST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved-By:  Henry Spencer <henry@SPSYSTEMS.NET>
Message-ID:  <Pine.BSI.3.91.1001128172422.1529N-100000@spsystems.net>
Date:         Tue, 28 Nov 2000 17:28:16 -0500
Reply-To: Henry Spencer <henry@spsystems.net>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Henry Spencer <henry@spsystems.net>
Subject:      Re: [MOBILE-IP] RFC 2401 section 5.2.1
X-To:         Dan Harkins <dharkins@cips.nokia.com>
X-cc:         Francis Dupont <Francis.Dupont@enst-bretagne.fr>,
              ipsec@lists.tislabs.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200011270152.RAA24730@potassium.network-alchemy.com>

On Sun, 26 Nov 2000, Dan Harkins wrote:
> > seems to us that tunnel mode actually gives slightly higher security,
> > because it obscures whether the communication really *is* end-to-end...
>
> Obscured from whom? Don't transport mode and tunnel mode packets look
> identical to a passive evesdropper since the Next Header field is encrypted?

Unless the senders are doing clever things with padding etc., on most
links he can quickly tell whether tunneling is being done by inspecting
the low end of the packet-length distribution.

                                                          Henry Spencer
                                                       henry@spsystems.net


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov 29 03:30:36 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10669
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 29 Nov 2000 03:30:36 -0500 (EST)
Received: from standards (47.234.32.16:2815) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC9BD@standards.nortelnetworks.com>; Wed, 29 Nov 2000 3:11:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 144899 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Nov 2000 03:11:21
          -0500
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBC9BB@standards.nortelnetworks.com>; Wed, 29 Nov 2000 3:11:20
          -0500
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr
          [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with
          ESMTP id eAT8SX425010; Wed, 29 Nov 2000 09:28:33 +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 JAA23867; Wed, 29 Nov 2000 09:28:33 +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.9.3/8.9.3) with
          ESMTP id JAA06750; Wed, 29 Nov 2000 09:28:37 +0100 (CET)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Approved-By:  Francis.Dupont@ENST-BRETAGNE.FR
Message-ID:  <200011290828.JAA06750@givry.rennes.enst-bretagne.fr>
Date:         Wed, 29 Nov 2000 09:28:37 +0100
Reply-To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject:      Re: [MOBILE-IP] Placement for Binding Update and Home Address opt
              ions
X-To:         Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Tue, 28 Nov 2000 17:00:52 CST. 
              <0DF9920C9AD8D211AB0C0008C7CF1C9A0498FCE4@il27exm02.cig.mot.com>

 In your previous mail you wrote:

   <MN> Could you please elaborate on what you mean by hacking the IPSec
   implementation, would you decrypt what comes after the ESP header?

=> there are two problems:
 - RFC 2401 mandates a check of the source address (inner one in tunnel mode)
   after each IPsec header processing. Richard's idea is to delay the check
   until the home address option is processed or to chase for it further
   in the packet.
 - RFC 2401 doesn't mandate a check of the outer source address in tunnel mode
   but many implementations do this, in general in the SA lookup routine
   (ie. very soon).

   Does it not add a lot to the processing burden?

=> it is a major change for some implementations but we don't know the
   proportion of implementations which can be affected or the weight of
   the burden...

   => if the attacker doesn't know its home address it can do nothing,
   if it knows then the protection relies on the mobile node policy
   (for instance it should not try to optimize the routing).

   <MN> I have to read about the creation of binding cache more seriously.
   According to what I am hearing, binding caches can be created regardless of
   SAs.

=> but they are created only on the reception of a valid (then authenticated,
this needs a SA) binding update.

   So if you know the mobile's home address, can you create a binding
   entry for yourself at the mobile's binding cache?

=> perhaps you mean the binding update list? An entry in it can be created
by any packet received by the mobile node if its policy accepts this (and
the usual policy is to do it at least for any packet received though the
tunnel with the home agent).

   and that way keep asking mobile about its c/o?

=> you don't need a binding update, the mobile will reveal its c/o address
in any answer. The only way to hide the c/o address is to use a reverse tunnel
from the mobile node to the home agent (ie. to use a fully not-optimized
version of mobile IPv6). If you want to secure the tunnel (ie. use ESP)
then you fallback in the IPsec tunnel + mobility issue again...

Thanks

Francis.Dupont@enst-bretagne.fr

PS: in the IPv4 world reverse tunnelling is optional but should be used
in many cases (because of ingress filtering for instance). In such cases
mobile IPv6 stuff can be used nearly as it (encapsulation and security
issues collapse to ESP tunnel).


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov 29 05:17:04 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28716
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 29 Nov 2000 05:17:04 -0500 (EST)
Received: from standards (47.234.32.16:3178) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBCA89@standards.nortelnetworks.com>; Wed, 29 Nov 2000 4:57:10 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 145174 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Nov 2000 04:57:09
          -0500
Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBCA87@standards.nortelnetworks.com>; Wed, 29 Nov 2000 4:57:09
          -0500
Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by
          ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id LAA09630; Wed, 29 Nov
          2000 11:14:25 +0100 (MET)
Received: from inrialpes.fr (localhost [127.0.0.1]) by glandon.inrialpes.fr
          (8.8.7/8.8.5) with ESMTP id LAA29157; Wed, 29 Nov 2000 11:14:24 +0100
          (MET)
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <4B6BC00CD15FD2119E5F0008C7A419A50C613EA3@eaubrnt018.epa.ericsson.se>
            <3A23F176.3A047674@iprg.nokia.com>
Content-Type: multipart/alternative;
              boundary="------------B1CF436ECCD99B4CE43FD425"
Approved-By:  Claude.Castelluccia@INRIALPES.FR
Message-ID:  <3A24D700.B925F806@inrialpes.fr>
Date:         Wed, 29 Nov 2000 11:14:24 +0100
Reply-To: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
Subject:      Re: [MOBILE-IP] IPv6 mobile routers vs. regional mobility agents
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

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


Hello Charlie,

The draft "Mobile Networks Support in Mobile IPv6"
(draft-ernst-mobileip-v6-network-01.txt)
that was just submitted to the IETF actually considers the issues that you
mention in your email...

We would really appreciated your comments on the draft if you have some time to
read it....

regards,
Claude.

PS: you can get the draft at
http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt



"Charles E. Perkins" wrote:

> Hello,
>
> I think there's another way to look at this problem of
> mobile routers that offers a "better" solution.  It isn't
> the same problem as has been discussed in connection with
> hiearchical mobility agents.  It should not be solved by
> techniques associated with hierarchical mobility agents.
> Nor anchor points, if I may use that terminology.  A mobile
> router should not necessarily be considered an anchor point
> or a regional mobility agent.
>
> The reason it is not the same is as follows:
>
> - With hierarchical mobility agents, the mobile node's home
>   agent can be shielded from having to know about local
>   care-of addresses, as long as it can supply a regional
>   care-of address to the home agent and supply local care-of
>   addresses to the regional mobility agent.
>
> - With mobile routers, the mobile node "should" be using
>   the prefix of a home address of the mobile router as the
>   prefix by which it forms its own care-of address.  This
>   could be done independently of any sort of hierarchical
>   mobility agent architecture.  In other words, there doesn't
>   have to be any regional mobility agent at all to make
>   a mobile router work.
>
> To see this in another way, suppose that the mobile router
> has a fixed Ethernet attached to it.  The nodes on the
> "mobile network" do not run Mobile IPv6.  Why should they
> deal with any advertised care-of addresses from the mobile
> router?
>
> However, this business about mobile routers does bring up
> interesting points.  Suppose the mobile node hooks up to
> a mobile router, and gets a prefix from the advertisement,
> and forms its care-of address.  Packets routed towards that
> care-of address are likely to go through the home agent
> for the mobile router.  The router's home agent will
> encapsulate them.  The mobile router will decapsulate them.
> At this point, the packet should be as issued originally
> by the correspondent node (with a routing header) or
> by the mobile node's home agent (i.e., encapsulated).
>
> Now suppose some corrspondent node is sending megabytes of
> data, with each packet having a routing header containing
> the mobile node's care-of address.
>
> We would like for that data not to have to go through the
> home agent for the mobile router.  That means that the
> correspondent node should get information about the care-of
> address for the _mobile router_.  Then, the correspondent node
> could put in a routing header with _two_ care-of addresses.
> The first one would be the care-of address for the mobile
> router, and the second one would be the care-of address
> for the mobile node.
>
> In order to do this directly, the mobile router would need
> some security association with the correspondent node.
> This is one area where this problem shows itself to be much
> different than the hierarchical mobility agent problem.
> For hierarchical mobility agents, there is a natural way
> to set up the security associations.  For the mobile router,
> the same security setup seems unlikely to work.  I didn't
> "map" it out yet, but I reckon some sort of redirect is
> the most likely candidate.  The mobile node can authentically
> "relay" a redirect from the mobile router to the correspondent
> node.  We would have to make some rules about this, but I
> think that what the correspondent node would see would be
> a Binding Update for the care-of address.  This has already
> been specified in another context for smooth handovers.
>
> I sure hope we don't have to do this before Mobile IPv6
> completes its Last Call.
>
> Regards,
> Charlie P.
>
> "Hesham Soliman (EPA)" wrote:
> >
> > > > > The question is:
> > > > > Is that a problem, if I receive already decapsulated datagrams, even
> > > > > if usually I decapsulate them by myself?!
> > > > >
> > > > > Clarifications are welcome.
> > > > >
> > > >         => Your scenario is supported in draft-ietf-mobileip-hmipv6-02
> > > >         which will be on the web very soon. I think you'll get the
> > > answer
> > > >         you're looking for there.
> > > >         But as a short answer, no there is no problem because the MN
> > > >         doesn't think that it moved since it is still sending and
> > > receiving
> > > >         packets using its Home address.
> > >
> > > The problem is just this:
> > > I would like the MN to know it moved, so it can update its CNs and its
> > > Home
> > > Agent by itself.
> > >
> >         => I realise that. That's exactly what the draft allows you to do.
> >         The MAP option is sent by the Mobile Router (MR), so the MN
> >         knows that it moved and that the MAP acts as a COA for it.
> >         The MN will update the HA and the CNs accordingly with an
> >         alternate-COA as specified in MIPv6. So route optimised
> >         packets will be received by the MAP (MR) and forwarded
> >         to the MN. Every thing happens end to end.
> >         Does that solve your problem ?
> >         Please see the draft for more info.
> >
> >         Regards,
> >         Hesham

--

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



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Hello Charlie,
<p>The draft "Mobile Networks Support in Mobile IPv6" (draft-ernst-mobileip-v6-network-01.txt)
<br>that was just submitted to the IETF actually considers the issues that
you mention in your email...
<p>We would really appreciated your comments on the draft if you have some
time to read it....
<p>regards,
<br>Claude.
<p>PS: you can get the draft at <A HREF="http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt">http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt</A>
<br>&nbsp;
<p>"Charles E. Perkins" wrote:
<blockquote TYPE=CITE>Hello,
<p>I think there's another way to look at this problem of
<br>mobile routers that offers a "better" solution.&nbsp; It isn't
<br>the same problem as has been discussed in connection with
<br>hiearchical mobility agents.&nbsp; It should not be solved by
<br>techniques associated with hierarchical mobility agents.
<br>Nor anchor points, if I may use that terminology.&nbsp; A mobile
<br>router should not necessarily be considered an anchor point
<br>or a regional mobility agent.
<p>The reason it is not the same is as follows:
<p>- With hierarchical mobility agents, the mobile node's home
<br>&nbsp; agent can be shielded from having to know about local
<br>&nbsp; care-of addresses, as long as it can supply a regional
<br>&nbsp; care-of address to the home agent and supply local care-of
<br>&nbsp; addresses to the regional mobility agent.
<p>- With mobile routers, the mobile node "should" be using
<br>&nbsp; the prefix of a home address of the mobile router as the
<br>&nbsp; prefix by which it forms its own care-of address.&nbsp; This
<br>&nbsp; could be done independently of any sort of hierarchical
<br>&nbsp; mobility agent architecture.&nbsp; In other words, there doesn't
<br>&nbsp; have to be any regional mobility agent at all to make
<br>&nbsp; a mobile router work.
<p>To see this in another way, suppose that the mobile router
<br>has a fixed Ethernet attached to it.&nbsp; The nodes on the
<br>"mobile network" do not run Mobile IPv6.&nbsp; Why should they
<br>deal with any advertised care-of addresses from the mobile
<br>router?
<p>However, this business about mobile routers does bring up
<br>interesting points.&nbsp; Suppose the mobile node hooks up to
<br>a mobile router, and gets a prefix from the advertisement,
<br>and forms its care-of address.&nbsp; Packets routed towards that
<br>care-of address are likely to go through the home agent
<br>for the mobile router.&nbsp; The router's home agent will
<br>encapsulate them.&nbsp; The mobile router will decapsulate them.
<br>At this point, the packet should be as issued originally
<br>by the correspondent node (with a routing header) or
<br>by the mobile node's home agent (i.e., encapsulated).
<p>Now suppose some corrspondent node is sending megabytes of
<br>data, with each packet having a routing header containing
<br>the mobile node's care-of address.
<p>We would like for that data not to have to go through the
<br>home agent for the mobile router.&nbsp; That means that the
<br>correspondent node should get information about the care-of
<br>address for the _mobile router_.&nbsp; Then, the correspondent node
<br>could put in a routing header with _two_ care-of addresses.
<br>The first one would be the care-of address for the mobile
<br>router, and the second one would be the care-of address
<br>for the mobile node.
<p>In order to do this directly, the mobile router would need
<br>some security association with the correspondent node.
<br>This is one area where this problem shows itself to be much
<br>different than the hierarchical mobility agent problem.
<br>For hierarchical mobility agents, there is a natural way
<br>to set up the security associations.&nbsp; For the mobile router,
<br>the same security setup seems unlikely to work.&nbsp; I didn't
<br>"map" it out yet, but I reckon some sort of redirect is
<br>the most likely candidate.&nbsp; The mobile node can authentically
<br>"relay" a redirect from the mobile router to the correspondent
<br>node.&nbsp; We would have to make some rules about this, but I
<br>think that what the correspondent node would see would be
<br>a Binding Update for the care-of address.&nbsp; This has already
<br>been specified in another context for smooth handovers.
<p>I sure hope we don't have to do this before Mobile IPv6
<br>completes its Last Call.
<p>Regards,
<br>Charlie P.
<p>"Hesham Soliman (EPA)" wrote:
<br>>
<br>> > > > The question is:
<br>> > > > Is that a problem, if I receive already decapsulated datagrams,
even
<br>> > > > if usually I decapsulate them by myself?!
<br>> > > >
<br>> > > > Clarifications are welcome.
<br>> > > >
<br>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; => Your scenario
is supported in draft-ietf-mobileip-hmipv6-02
<br>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; which will be
on the web very soon. I think you'll get the
<br>> > answer
<br>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; you're looking
for there.
<br>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; But as a short
answer, no there is no problem because the MN
<br>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; doesn't think
that it moved since it is still sending and
<br>> > receiving
<br>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packets using
its Home address.
<br>> >
<br>> > The problem is just this:
<br>> > I would like the MN to know it moved, so it can update its CNs
and its
<br>> > Home
<br>> > Agent by itself.
<br>> >
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; => I realise that.
That's exactly what the draft allows you to do.
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The MAP option is
sent by the Mobile Router (MR), so the MN
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; knows that it moved
and that the MAP acts as a COA for it.
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The MN will update
the HA and the CNs accordingly with an
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; alternate-COA as
specified in MIPv6. So route optimised
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packets will be received
by the MAP (MR) and forwarded
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to the MN. Every
thing happens end to end.
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Does that solve your
problem ?
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Please see the draft
for more info.
<br>>
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Regards,
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hesham</blockquote>

<pre>--&nbsp;

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

--------------B1CF436ECCD99B4CE43FD425--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov 29 08:14:39 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16093
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 29 Nov 2000 08:14:38 -0500 (EST)
Received: from standards (47.234.32.16:3155) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBCBAE@standards.nortelnetworks.com>; Wed, 29 Nov 2000 7:55:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 145565 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Nov 2000 07:55:22
          -0500
Received: from dv.op.dlr.de (n13.sp.op.dlr.de) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBCBAC@standards.nortelnetworks.com>; Wed, 29 Nov 2000 7:55:22
          -0500
Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) by
          dv.op.dlr.de (8.10.1/8.10.1) with ESMTP id eATDCaZ25612; Wed, 29 Nov
          2000 14:12:36 +0100
Received: from zeus.nt.op.dlr.de (pcdn183_nt_op [129.247.173.183]) by
          zeus.nt.op.dlr.de (8.9.1b+Sun/8.9.1) with ESMTP id OAA08670; Wed, 29
          Nov 2000 14:12:30 +0100 (MET)
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------5E63B90A813002FCA482020F"
Approved-By:  Matteo Berioli <berioli@ZEUS.NT.OP.DLR.DE>
Message-ID:  <3A2500C4.6577638A@zeus.nt.op.dlr.de>
Date:         Wed, 29 Nov 2000 14:12:37 +0100
Reply-To: mberio@libero.it
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Matteo Berioli <berioli@zeus.nt.op.dlr.de>
Subject:      [MOBILE-IP] Registration Reply in Mobile IP
X-cc:         perk@watson.ibm.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

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

I'm looking for the complete list of all the possible values of CODE
field in the Registration Reply message of Mobile IP.
In RFC 2002 of Mobile IP, page 32, it is said:

Up-to-date values of the Code field are specified in the most recent
   "Assigned Numbers" [20].

But I cannot find it!
Anybody can help me?!

Thanks,
Matteo

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I'm looking for the complete list of all the possible values of CODE field
in the Registration Reply message of Mobile IP.
<br>In <a href="http://www.ietf.org/rfc/rfc2002.txt?number=2002">RFC 2002</a>
of Mobile IP, page 32, it is said:
<p>Up-to-date values of the Code field are specified in the most recent
<br>&nbsp;&nbsp; "Assigned Numbers" [20].
<p>But I cannot find it!
<br>Anybody can help me?!
<p>Thanks,
<br>Matteo</html>

--------------5E63B90A813002FCA482020F--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov 29 10:33:58 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08376
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 29 Nov 2000 10:33:57 -0500 (EST)
Received: from standards (47.234.32.16:2259) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBCCA3@standards.nortelnetworks.com>; Wed, 29 Nov 2000 10:14:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 145903 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Nov 2000 10:14:44
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBCCA1@standards.nortelnetworks.com>; Wed, 29 Nov 2000 10:14:43
          -0500
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA17231;
          Wed, 29 Nov 2000 07:32:00 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id eATFVxn12035; Wed, 29 Nov 2000 07:31:59
          -0800
X-Virus-Scanned:  Wed, 29 Nov 2000 07:31:59 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpd74trBF; Wed, 29 Nov 2000
          07:31:53 PST
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <3A2500C4.6577638A@zeus.nt.op.dlr.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  charliep@IPRG.NOKIA.COM
Message-ID:  <3A25216A.24FD63C9@iprg.nokia.com>
Date:         Wed, 29 Nov 2000 07:31:54 -0800
Reply-To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] Registration Reply in Mobile IP
X-To:         mberio@libero.it
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Matteo,

Try http://www.iana.org/numbers.html, and work down from there.

Regards,
Charlie P.


Matteo Berioli wrote:
>
> I'm looking for the complete list of all the possible values of CODE field in
> the Registration Reply message of Mobile IP.
> In RFC 2002 of Mobile IP, page 32, it is said:
>
> Up-to-date values of the Code field are specified in the most recent
>    "Assigned Numbers" [20].
>
> But I cannot find it!
> Anybody can help me?!
>
> Thanks,
> Matteo


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov 29 11:23:06 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26686
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 29 Nov 2000 11:23:05 -0500 (EST)
Received: from standards (47.234.32.16:4854) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBCD27@standards.nortelnetworks.com>; Wed, 29 Nov 2000 11:03:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 146090 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Nov 2000 11:03:58
          -0500
Received: from dv.op.dlr.de (n13.sp.op.dlr.de) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBCD25@standards.nortelnetworks.com>; Wed, 29 Nov 2000 11:03:57
          -0500
Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) by
          dv.op.dlr.de (8.10.1/8.10.1) with ESMTP id eATGLEZ65428; Wed, 29 Nov
          2000 17:21:14 +0100
Received: from zeus.nt.op.dlr.de (pcdn183_nt_op [129.247.173.183]) by
          zeus.nt.op.dlr.de (8.9.1b+Sun/8.9.1) with ESMTP id RAA09782; Wed, 29
          Nov 2000 17:21:14 +0100 (MET)
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <3A2500C4.6577638A@zeus.nt.op.dlr.de>
            <3A25216A.24FD63C9@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Matteo Berioli <berioli@ZEUS.NT.OP.DLR.DE>
Message-ID:  <3A252D00.70C95E8A@zeus.nt.op.dlr.de>
Date:         Wed, 29 Nov 2000 17:21:21 +0100
Reply-To: mberio@libero.it
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Matteo Berioli <berioli@zeus.nt.op.dlr.de>
Subject:      Re: [MOBILE-IP] Registration Reply in Mobile IP
X-To:         "Charles E. Perkins" <charliep@IPRG.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

OK, I don't find the answer I'm looking for.
Let us assume that two different mobile nodes ask the Foreign Agent to register the
same Co-located CoA simultaneously.
For example the FA could forward only one of the 2 requests, and send to the other
MN a Registration Reply with a particular value in the CODE field.
That value could just mean that the registration would be successful simply
changing the Co-located CoA requested.
As a matter of fact that address, that was free only a minute before, has just been
taken by another MN.
Cannot the FA communicate what happened through a Registration Reply with a
particular CODE field?! Doesn't such a  message exist?

Thanks,
Matteo

"Charles E. Perkins" wrote:

> Hello Matteo,
>
> Try http://www.iana.org/numbers.html, and work down from there.
>
> Regards,
> Charlie P.
>
> Matteo Berioli wrote:
> >
> > I'm looking for the complete list of all the possible values of CODE field in
> > the Registration Reply message of Mobile IP.
> > In RFC 2002 of Mobile IP, page 32, it is said:
> >
> > Up-to-date values of the Code field are specified in the most recent
> >    "Assigned Numbers" [20].
> >
> > But I cannot find it!
> > Anybody can help me?!
> >
> > Thanks,
> > Matteo


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov 29 12:02:49 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11572
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 29 Nov 2000 12:02:48 -0500 (EST)
Received: from standards (47.234.32.16:4854) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBCD9B@standards.nortelnetworks.com>; Wed, 29 Nov 2000 11:43:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 146242 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Nov 2000 11:43:22
          -0500
Received: from odin2.bull.net by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBCD99@standards.nortelnetworks.com>; Wed, 29 Nov 2000 11:43:22
          -0500
Received: from ecbull20.frec.bull.fr (ecbull20.frec.bull.fr [129.183.4.3]) by
          odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA52284 for
          <MOBILE-IP@standards.nortelnetworks.com>; Wed, 29 Nov 2000 18:06:49
          +0100
Received: from isatis.frec.bull.fr (isatis.frec.bull.fr [129.183.144.1]) by
          ecbull20.frec.bull.fr (8.9.2/8.9.1) with ESMTP id SAA20002 for
          <MOBILE-IP@standards.nortelnetworks.com>; Wed, 29 Nov 2000 18:00:09
          +0100
Received: from bull.net (localhost [127.0.0.1]) by isatis.frec.bull.fr
          (AIX4.2/UCB 8.7/8.7) with ESMTP id SAA150498 for
          <MOBILE-IP@standards.nortelnetworks.com>; Wed, 29 Nov 2000 18:00:07
          +0100 (NFT)
X-Mailer: Mozilla 4.06 [en] (X11; I; AIX 4.2)
MIME-Version: 1.0
References: <200011282012.VAA03988@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Aime.Le-Rouzic@BULL.NET
Message-ID:  <3A253617.ED9E2F28@bull.net>
Date:         Wed, 29 Nov 2000 18:00:07 +0100
Reply-To: AIme.Le-Rouzic@bull.net
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: AIme Le-Rouzic <Aime.Le-Rouzic@bull.net>
Organization: Bull
Subject:      Re: [MOBILE-IP] WG Last Call: Mobile IPv6:draft-ietf-mobileip-ipv
              6-13.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Francis Dupont wrote:


> => the home address should be before the IPsec header(s) because:
>  - this works with any IPsec implementation on the receiving side
>    (don't forget the receiving side is the general one then the complexity
>     if you can't avoid it should be on the sending side)
>  - this is (very) firewall friendly. I don't like firewalls (I prefer IPsec)
>    but I believe we may not in the same time propose something which
>    bypass ingress-filtering (the home address option) and make it totally
>    firewall unfriendly (ie. suggest to hide it behind an ESP).
> I'd like to get the firewall people opinion at the IETF last call...

I think draft13 is good like it is because it allows
vendors to offer solutions for those mobile users who
only want authentication because the AH transport mode
and solutions for those mobile users who want to also
cipher datas by having the AH+ESP transport mode.

It allows also administrators to let go through the
border of their intranet the mobile packets by having
the Home address option in front  of the ESP header.
Without being able to control them, the network
administrators  will block and good bye mobile users.


The draft13 allows to show the interest of MobileIPv6
and then IPv6 that MobileIPv6 should boost.

Best regards.


--
     ________________________Aime LEROUZIC____________________________
     BULL S.A ECHIROLLES FRANCE      mailto:Aime.Lerouzic@frec.bull.fr
     http://www-frec.bull.com                tel: +33 (0)4 76 29 75 51
     Communications TCPIP                     http://intranet/lerouzic


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Nov 29 20:14:32 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00760
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 29 Nov 2000 20:14:31 -0500 (EST)
Received: from standards (47.234.32.16:3440) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD067@standards.nortelnetworks.com>; Wed, 29 Nov 2000 19:55:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 147210 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Nov 2000 19:55:04
          -0500
Received: from extmx.itri.org.tw by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBD065@standards.nortelnetworks.com>; Wed, 29 Nov 2000 19:54:59
          -0500
Received: from mail3.itri.org.tw (mail3.itri.org.tw [140.96.157.3]) by
          extmx.itri.org.tw (8.8.8/8.8.8) with ESMTP id JAA29174; Thu, 30 Nov
          2000 09:14:00 +0800 (CST)
Received: from nti.itri.org.tw (nti.itri.org.tw [140.96.157.2]) by
          mail3.itri.org.tw (8.9.3+Sun/8.9.1) with ESMTP id JAA25902; Thu, 30
          Nov 2000 09:15:11 +0800 (CST)
Received: from tsao (pc104125.ccl.itri.org.tw [140.96.104.125]) by
          nti.itri.org.tw (8.8.8/8.8.8) with SMTP id JAA23206; Thu, 30 Nov 2000
          09:11:13 +0800 (CST)
References:  <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D305@il27exm03.cig.mot.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0040_01C05AAD.ACCB4AA0"
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
Approved-By:  Shiao-Li Charles Tsao <sltsao@CCL.ITRI.ORG.TW>
Message-ID:  <004301c05a6a$9f06cc70$7d68608c@tsao>
Date:         Thu, 30 Nov 2000 09:12:34 +0800
Reply-To: Shiao-Li Charles Tsao <sltsao@ccl.itri.org.tw>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Shiao-Li Charles Tsao <sltsao@ccl.itri.org.tw>
Subject:      Re: [MOBILE-IP] draft agenda
X-To:         Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0040_01C05AAD.ACCB4AA0
Content-Type: text/plain;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Dear All,=20

My presentation on "Introducing Mobile IP in IPv4/IPv6 Interconnected =
networks" will based on two I-Ds.=20
1. Mobility Support for IPv4 and IPv6 Interconnected Networks based on =
Dual-Stack Model
draft-tsao-mobileip-duelstack-model-01.txt
http://www.geocities.com/mobileip_interworking/draft-tsao-mobileip-dualst=
ack-model-01.txt

2. Mobile IP Application Level Gateway
draft-tsao-mobileip-alg-00.txt
http://www.geocities.com/mobileip_interworking/draft-tsao-mobileip-alg-00=
.txt

I do appreciate for any comment and suggestion, Thanks !!!

Shiao-Li Tsao





----- Original Message -----=20
From: "Roberts Philip-qa3445" <Philip_Roberts-qa3445@email.mot.com>
To: <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Sent: Wednesday, November 29, 2000 12:38 AM
Subject: [MOBILE-IP] draft agenda


> Here it is, folks.  We have some specific goals we'd like to =
accomplish at this meeting and the time will be made available to get =
those done.  We'd like to get the v6 draft wrapped up.  It's in last =
call now and we'd like to reconcile all remaining issues by the end of =
the San Diego meeting.  We'd like to reach agreement on a single draft =
to be working group document for MIP v4 fast handoff.  We'd like to =
reach agreement on a single draft to be working group document for MIP =
v6 fast handoff.
>=20
>=20
> Thursday 9-11:30 (150 minutes)
> Raj             10      Agenda bashing and wg document status
> Charlie Perkins 15      MIPv6 Update                            =
draft-ietf-mobileip-ipv6-13.txt
> Vijay Devarapali        5       MIPv6 ETSI Bake-off Report
>=20
> Mobile IP V4 fast handoff:
> Pat Calhoun     5       Proactive handoff                              =
 draft-calhoun-mobileip-proactive-fa-02.txt
> Hesham Soliman  5       Fast handoff                            =
draft-elmalki-mobileip-fast-handoffs-03.txt
> McCann/Soliman  5       Summary  of differences in v4 handoff
> WG              15      Discussion of fast handoff in v4
>=20
> Mobile IP V6 fast handoff:
> Charlie Perkins 15      v6 fast handoff design team
>=20
>=20
>=20
> Hesham Soliman  10      Hierarchical MIP v6                     =
draft-ietf-mobileip-hmipv6-01.txt
> Pat Calhoun     5       Mobile IP and GRE enhancements          =
draft-calhoun-mobileip-gre-ext-00.txt
> Charlie Perkins 10      DIAMETER extensions for MIP             =
draft-calhoun-diameter-mobileip-11.txt
> Charlie Perkins 10      AAAv6 for MIP
> Steve Glass     15      Registration Revocation for Mobile IP   =
draft-glass-mobileip-reg-revok-00.txt
> Samita Chakrabarti 10   Private addressing                             =
 draft-ietf-mobileip-rfc2344-bis-03.txt
>=20
> Friday 9-11:30 (150 minutes)
> Hemant Chaskar  10      A Framework for QoS Support in MIP v6   =
draft-chaskar-mobileip-qos-00.txt
> Glenn Morrow    15      Intercepting Location Updates           =
draft-lmk-mobileip-intercepting-update-00.txt
> Hesham Soliman  10      Security association establishment for route =
optimization in v6 draft-soliman-mobileip-routeopt-mipv6-00.txt
> Charlie Pekins  10      IP v6 Regional Registration             =
draft-malinen-mobileip-regreg6-00.txt
> SL Tsao         15      Introducing Mobile IP in IPv4/IPv6 =
Interconnected networks                                      =
draft-tsao-mobileip-duelstack-model-00.txt
> Steve Glass     10      Use of DHCP in Mobile IP                =
draft-glass-mobileip-agent-dhcp-proxy-00.txt
> Ernst Thierry   10      Mobile Network Support                  =
draft-ernst-mobileip-v6-network-00.txt
> Jari Malinen    5       GSM SIM authentication                  =
draft-haverinen-mobileip-gsmsim-00.txt
> Jiwoong Lee     6       SGM support in MIP                      =
draft-lee-sgm-support-mobileip-00.txt
>=20
>=20
> Pekka Nikander  10      Mobile IP v6 for the Homeless           =
draft-nikander-mobileip-homelessv6-00.txt
> Behcet Sarikaya 5       Mobile IP v6 Regional Paging            =
draft-sarikaya-mobileip-hmipv6rp-00
>=20

------=_NextPart_000_0040_01C05AAD.ACCB4AA0
Content-Type: text/html;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3D"Courier New" size=3D2>Dear All, </FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>My presentation on "Introducing =
Mobile IP=20
in IPv4/IPv6 Interconnected networks" will based on two I-Ds. =
</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>1. Mobility Support for IPv4 =
and IPv6=20
Interconnected Networks&nbsp;based on Dual-Stack Model</FONT></DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2>draft-tsao-mobileip-duelstack-model-01.txt</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><A=20
href=3D"http://www.geocities.com/mobileip_interworking/draft-tsao-mobilei=
p-dualstack-model-01.txt">http://www.geocities.com/mobileip_interworking/=
draft-tsao-mobileip-dualstack-model-01.txt</A><BR></DIV></FONT>
<DIV><FONT face=3D"Courier New" size=3D2>2. Mobile IP Application Level=20
Gateway</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>
<DIV><FONT face=3D"Courier New" =
size=3D2>draft-tsao-mobileip-alg-00.txt</FONT></DIV>
<DIV><A=20
href=3D"http://www.geocities.com/mobileip_interworking/draft-tsao-mobilei=
p-alg-00.txt">http://www.geocities.com/mobileip_interworking/draft-tsao-m=
obileip-alg-00.txt</A></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>I do appreciate for any comment =
and=20
suggestion, Thanks !!!</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>Shiao-Li Tsao</DIV>
<DIV></FONT>&nbsp;</DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>----- Original Message ----- =
</FONT>
<DIV><FONT face=3D"Courier New" size=3D2>From: "Roberts Philip-qa3445" =
&lt;</FONT><A=20
href=3D"mailto:Philip_Roberts-qa3445@email.mot.com"><FONT =
face=3D"Courier New"=20
size=3D2>Philip_Roberts-qa3445@email.mot.com</FONT></A><FONT =
face=3D"Courier New"=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>To: &lt;</FONT><A=20
href=3D"mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM"><FONT =
face=3D"Courier New"=20
size=3D2>MOBILE-IP@STANDARDS.NORTELNETWORKS.COM</FONT></A><FONT =
face=3D"Courier New"=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Sent: Wednesday, November 29, =
2000 12:38=20
AM</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Subject: [MOBILE-IP] draft=20
agenda</FONT></DIV></DIV>
<DIV><BR></DIV><FONT face=3D"Courier New" size=3D2>&gt; Here it is, =
folks.&nbsp; We=20
have some specific goals we'd like to accomplish at this meeting and the =
time=20
will be made available to get those done.&nbsp; We'd like to get the v6 =
draft=20
wrapped up.&nbsp; It's in last call now and we'd like to reconcile all =
remaining=20
issues by the end of the San Diego meeting.&nbsp; We'd like to reach =
agreement=20
on a single draft to be working group document for MIP v4 fast =
handoff.&nbsp;=20
We'd like to reach agreement on a single draft to be working group =
document for=20
MIP v6 fast handoff.<BR>&gt; <BR>&gt; <BR>&gt; Thursday 9-11:30 (150=20
minutes)<BR>&gt;=20
Raj&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Agenda bashing and wg document =
status<BR>&gt;=20
Charlie Perkins 15&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIPv6=20
Update&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
draft-ietf-mobileip-ipv6-13.txt<BR>&gt; Vijay=20
Devarapali&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIPv6 ETSI Bake-off Report<BR>&gt; =

<BR>&gt; Mobile IP V4 fast handoff:<BR>&gt; Pat =
Calhoun&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Proactive=20
handoff&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
draft-calhoun-mobileip-proactive-fa-02.txt<BR>&gt; Hesham Soliman&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fast=20
handoff&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
draft-elmalki-mobileip-fast-handoffs-03.txt<BR>&gt; McCann/Soliman&nbsp; =

5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Summary&nbsp; of differences in v4 =

handoff<BR>&gt;=20
WG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
15&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Discussion of fast handoff in =
v4<BR>&gt;=20
<BR>&gt; Mobile IP V6 fast handoff:<BR>&gt; Charlie Perkins=20
15&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v6 fast handoff design team<BR>&gt; =
<BR>&gt;=20
<BR>&gt; <BR>&gt; Hesham Soliman&nbsp; 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Hierarchical MIP=20
v6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
draft-ietf-mobileip-hmipv6-01.txt<BR>&gt; Pat =
Calhoun&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile IP and GRE=20
enhancements&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
draft-calhoun-mobileip-gre-ext-00.txt<BR>&gt; Charlie Perkins=20
10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DIAMETER extensions for=20
MIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
draft-calhoun-diameter-mobileip-11.txt<BR>&gt; Charlie Perkins=20
10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AAAv6 for MIP<BR>&gt; Steve=20
Glass&nbsp;&nbsp;&nbsp;&nbsp; 15&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Registration=20
Revocation for Mobile IP&nbsp;&nbsp;=20
draft-glass-mobileip-reg-revok-00.txt<BR>&gt; Samita Chakrabarti =
10&nbsp;&nbsp;=20
Private=20
addressing&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
draft-ietf-mobileip-rfc2344-bis-03.txt<BR>&gt; <BR>&gt; Friday 9-11:30 =
(150=20
minutes)<BR>&gt; Hemant Chaskar&nbsp; 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A =

Framework for QoS Support in MIP v6&nbsp;&nbsp;=20
draft-chaskar-mobileip-qos-00.txt<BR>&gt; Glenn Morrow&nbsp;&nbsp;&nbsp; =

15&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Intercepting Location=20
Updates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
draft-lmk-mobileip-intercepting-update-00.txt<BR>&gt; Hesham =
Soliman&nbsp;=20
10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Security association establishment for =
route=20
optimization in v6 draft-soliman-mobileip-routeopt-mipv6-00.txt<BR>&gt; =
Charlie=20
Pekins&nbsp; 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IP v6 Regional=20
Registration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
draft-malinen-mobileip-regreg6-00.txt<BR>&gt; SL=20
Tsao&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
15&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Introducing Mobile IP in IPv4/IPv6=20
Interconnected=20
networks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
draft-tsao-mobileip-duelstack-model-00.txt<BR>&gt; Steve=20
Glass&nbsp;&nbsp;&nbsp;&nbsp; 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Use of =
DHCP in=20
Mobile=20
IP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=20
draft-glass-mobileip-agent-dhcp-proxy-00.txt<BR>&gt; Ernst =
Thierry&nbsp;&nbsp;=20
10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile Network=20
Support&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
draft-ernst-mobileip-v6-network-00.txt<BR>&gt; Jari =
Malinen&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GSM SIM=20
authentication&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
draft-haverinen-mobileip-gsmsim-00.txt<BR>&gt; Jiwoong=20
Lee&nbsp;&nbsp;&nbsp;&nbsp; 6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SGM =
support in=20
MIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
draft-lee-sgm-support-mobileip-00.txt<BR>&gt; <BR>&gt; <BR>&gt; Pekka=20
Nikander&nbsp; 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile IP v6 for the=20
Homeless&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
draft-nikander-mobileip-homelessv6-00.txt<BR>&gt; Behcet Sarikaya=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile IP v6 Regional=20
Paging&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

draft-sarikaya-mobileip-hmipv6rp-00<BR>&gt; </FONT></BODY></HTML>

------=_NextPart_000_0040_01C05AAD.ACCB4AA0--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 30 09:21:38 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22988
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Nov 2000 09:21:33 -0500 (EST)
Received: from standards (47.234.32.16:2824) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD320@standards.nortelnetworks.com>; Thu, 30 Nov 2000 9:02:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 148096 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 09:02:06
          -0500
Received: from patan.sun.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBD31E@standards.nortelnetworks.com>;
          Thu, 30 Nov 2000 9:02:01 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com
          (8.9.3+Sun/8.9.3) with ESMTP id GAA28472 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30 Nov 2000 06:19:20
          -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          GAA04483 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30 Nov
          2000 06:19:19 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id GAA21663 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30 Nov 2000 06:19:19
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Pat Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.975593781.22045.pcalhoun@nasnfs>
Date:         Thu, 30 Nov 2000 06:16:21 -0800
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      [MOBILE-IP] I-D ACTION:draft-perkins-mobileip-handover-00.txt
              (Fwd)
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" <200011301052.FAA25928@ietf.org>

All (and chairs),

I am very happy to see that the v6 design team was able to get a draft issued
prior to the deadline. However, I have a small question. In the past weeks, it
seems like I've seen at least half a dozen fast handoff I-Ds for v6. It was my
understanding that the design team's I-D would be the one the WG would work
with as a base. Is this assumption still correct, or should we also be reading
the many other documents? (seems like we are nearly at the same point we were
in Pittsburgh :(

PatC

>----------------Begin Forwarded Message----------------<

Date: Thu, 30 Nov 2000 05:52:43 -0500
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-perkins-mobileip-handover-00.txt
To: IETF-Announce@, @

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


        Title           : Fast Handovers for Mobile IPv6
        Author(s)       : C. Perkins et al.
        Filename        : draft-perkins-mobileip-handover-00.txt
        Pages           : 24
        Date            : 29-Nov-00

This document identifies (OR BETTER: specifies) protocol enhancements
that enable mobile nodes to more quickly become connected at new
points of attachment to the Internet.  These protocol enhancements
are intended to minimize the time during which the mobile node is
unable to send or receive IPv6 packets (i.e., the handover latency).
Mobile IPv6 is considered to be the base protocol, but Mobile
IPv6 does not mandate any mechanism which gives assurances about
minimizing the handover latency.  The protocol enhancements in this
document should be considered as protocol enhancements to Mobile
IPv6.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-perkins-mobileip-handover-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-perkins-mobileip-handover-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@STANDARDS.NORTELNETWORKS.COM  Thu Nov 30 09:30:35 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27497
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Nov 2000 09:30:34 -0500 (EST)
Received: from standards (47.234.32.16:2824) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD361@standards.nortelnetworks.com>; Thu, 30 Nov 2000 9:11:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 148179 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 09:11:12
          -0500
Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBD35F@standards.nortelnetworks.com>; Thu, 30 Nov 2000 9:11:11
          -0500
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          motgate.mot.com (motgate 2.1) with ESMTP id HAA22822 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30 Nov 2000 07:28:32
          -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100])
          by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id HAA12192 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30 Nov 2000 07:28:31
          -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2651.58) id
          <WQNK4PML>; Thu, 30 Nov 2000 08:28:25 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  Roberts Philip-qa3445 <Philip_Roberts-qa3445@EMAIL.MOT.COM>
Message-ID:  <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D333@il27exm03.cig.mot.com>
Date:         Thu, 30 Nov 2000 08:28:28 -0600
Reply-To: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Subject:      Re: [MOBILE-IP] I-D ACTION:draft-perkins-mobileip-handover-00.txt
              (Fwd)
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a good question, Pat.  I think for the time being we're all going to have to keep reading.  Our goal was and still is that the v6 design team produce a draft that is the working group document on v6 fast handover.  I know that some of the other drafts are written by members of the design team so I'd assume that the issues they want addressed are addressed within the design team document.  I don't know whether the drafts written by folks who aren't part of the design team will be very similar to or far different from what the design team has produced.

We'll have a discussion in San Diego on whether the design team draft is a good basis for the working group item on fast handover for v6 and whether other issues need be or can be incorporated into the draft.  Please be prepared.

Phil


> ----------
> From:         Pat Calhoun
> Reply To:     Pat Calhoun
> Sent:         Thursday, November 30, 2000 10:16 PM
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      [MOBILE-IP] I-D ACTION:draft-perkins-mobileip-handover-00.txt             (Fwd)
>
> All (and chairs),
>
> I am very happy to see that the v6 design team was able to get a draft issued
> prior to the deadline. However, I have a small question. In the past weeks, it
> seems like I've seen at least half a dozen fast handoff I-Ds for v6. It was my
> understanding that the design team's I-D would be the one the WG would work
> with as a base. Is this assumption still correct, or should we also be reading
> the many other documents? (seems like we are nearly at the same point we were
> in Pittsburgh :(
>
> PatC
>
> >----------------Begin Forwarded Message----------------<
>
> Date: Thu, 30 Nov 2000 05:52:43 -0500
> From: Internet-Drafts@ietf.org
> Subject: I-D ACTION:draft-perkins-mobileip-handover-00.txt
> To: IETF-Announce@, @
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>         Title           : Fast Handovers for Mobile IPv6
>         Author(s)       : C. Perkins et al.
>         Filename        : draft-perkins-mobileip-handover-00.txt
>         Pages           : 24
>         Date            : 29-Nov-00
>
> This document identifies (OR BETTER: specifies) protocol enhancements
> that enable mobile nodes to more quickly become connected at new
> points of attachment to the Internet.  These protocol enhancements
> are intended to minimize the time during which the mobile node is
> unable to send or receive IPv6 packets (i.e., the handover latency).
> Mobile IPv6 is considered to be the base protocol, but Mobile
> IPv6 does not mandate any mechanism which gives assurances about
> minimizing the handover latency.  The protocol enhancements in this
> document should be considered as protocol enhancements to Mobile
> IPv6.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-perkins-mobileip-handover-00.txt
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-perkins-mobileip-handover-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-perkins-mobileip-handover-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@STANDARDS.NORTELNETWORKS.COM  Thu Nov 30 14:37:27 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13584
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Nov 2000 14:37:26 -0500 (EST)
Received: from standards (47.234.32.16:4954) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD5B2@standards.nortelnetworks.com>; Thu, 30 Nov 2000 14:17:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 148991 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 14:17:31
          -0500
Received: from mailhub1.shef.ac.uk by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBD5B0@standards.nortelnetworks.com>; Thu, 30 Nov 2000 14:17:31
          -0500
Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk
          with esmtp (Exim 3.16 #1) id 141ZTY-0003tc-00; Thu, 30 Nov 2000
          19:34:36 +0000
Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 30
          Nov 00 19:34:37 +0000
Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 30 Nov 00 19:34:23 +0000
Received: from Mobile1 (143.167.59.139) by ridingwood.shef.ac.uk (Mercury
          1.48); 30 Nov 00 19:34:23 +0000
References:  <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D305@il27exm03.cig.mot.com>
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
Approved-By:  cnyap <cny@DCS.SHEF.AC.UK>
Message-ID:  <017301c05b04$23cda390$923ba78f@Mobile1>
Date:         Thu, 30 Nov 2000 19:31:30 -0000
Reply-To: cnyap <cny@ieee.org>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: cnyap <cny@dcs.shef.ac.uk>
Subject:      Re: [MOBILE-IP] draft agenda
X-To:         Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi

I wonder is "Mobile IP v6 for the Homeless" in charter of working group.

Chern Nam Yap
MIEEE, MSc(Res), BSc(Hons)
Research Associate
Center for Mobile Communication Research
Department of Electronic and Electrical Engineering
University of Sheffield
F132 Mappin Building
Mappin Street
Sheffield S1 3JD
United Kingdom
Tel:+44 (0) 114-222-5182
Mobile:+ 44(0) 7712804892
Web: www.mobile1.net
E-mail: cny@ieee.org



----- Original Message -----
From: "Roberts Philip-qa3445" <Philip_Roberts-qa3445@email.mot.com>
To: <MOBILE-IP@standards.nortelnetworks.com>
Sent: Tuesday, November 28, 2000 4:38 PM
Subject: [MOBILE-IP] draft agenda


> Here it is, folks.  We have some specific goals we'd like to accomplish at
this meeting and the time will be made available to get those done.  We'd
like to get the v6 draft wrapped up.  It's in last call now and we'd like to
reconcile all remaining issues by the end of the San Diego meeting.  We'd
like to reach agreement on a single draft to be working group document for
MIP v4 fast handoff.  We'd like to reach agreement on a single draft to be
working group document for MIP v6 fast handoff.
>
>
> Thursday 9-11:30 (150 minutes)
> Raj             10      Agenda bashing and wg document status
> Charlie Perkins 15      MIPv6 Update
draft-ietf-mobileip-ipv6-13.txt
> Vijay Devarapali        5       MIPv6 ETSI Bake-off Report
>
> Mobile IP V4 fast handoff:
> Pat Calhoun     5       Proactive handoff
draft-calhoun-mobileip-proactive-fa-02.txt
> Hesham Soliman  5       Fast handoff
draft-elmalki-mobileip-fast-handoffs-03.txt
> McCann/Soliman  5       Summary  of differences in v4 handoff
> WG              15      Discussion of fast handoff in v4
>
> Mobile IP V6 fast handoff:
> Charlie Perkins 15      v6 fast handoff design team
>
>
>
> Hesham Soliman  10      Hierarchical MIP v6
draft-ietf-mobileip-hmipv6-01.txt
> Pat Calhoun     5       Mobile IP and GRE enhancements
draft-calhoun-mobileip-gre-ext-00.txt
> Charlie Perkins 10      DIAMETER extensions for MIP
draft-calhoun-diameter-mobileip-11.txt
> Charlie Perkins 10      AAAv6 for MIP
> Steve Glass     15      Registration Revocation for Mobile IP
draft-glass-mobileip-reg-revok-00.txt
> Samita Chakrabarti 10   Private addressing
draft-ietf-mobileip-rfc2344-bis-03.txt
>
> Friday 9-11:30 (150 minutes)
> Hemant Chaskar  10      A Framework for QoS Support in MIP v6
draft-chaskar-mobileip-qos-00.txt
> Glenn Morrow    15      Intercepting Location Updates
draft-lmk-mobileip-intercepting-update-00.txt
> Hesham Soliman  10      Security association establishment for route
optimization in v6 draft-soliman-mobileip-routeopt-mipv6-00.txt
> Charlie Pekins  10      IP v6 Regional Registration
draft-malinen-mobileip-regreg6-00.txt
> SL Tsao         15      Introducing Mobile IP in IPv4/IPv6 Interconnected
networks
draft-tsao-mobileip-duelstack-model-00.txt
> Steve Glass     10      Use of DHCP in Mobile IP
draft-glass-mobileip-agent-dhcp-proxy-00.txt
> Ernst Thierry   10      Mobile Network Support
draft-ernst-mobileip-v6-network-00.txt
> Jari Malinen    5       GSM SIM authentication
draft-haverinen-mobileip-gsmsim-00.txt
> Jiwoong Lee     6       SGM support in MIP
draft-lee-sgm-support-mobileip-00.txt
>
>
> Pekka Nikander  10      Mobile IP v6 for the Homeless
draft-nikander-mobileip-homelessv6-00.txt
> Behcet Sarikaya 5       Mobile IP v6 Regional Paging
draft-sarikaya-mobileip-hmipv6rp-00
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 30 15:01:27 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22281
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Nov 2000 15:01:27 -0500 (EST)
Received: from standards (47.234.32.16:4954) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD605@standards.nortelnetworks.com>; Thu, 30 Nov 2000 14:42:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 149100 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 14:42:11
          -0500
Received: from d248-38.pekka.nikander.com (d248-38.arenanet.fi) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBD603@standards.nortelnetworks.com>; Thu, 30 Nov 2000
          14:42:10 -0500
Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.43]) by
          d248-38.pekka.nikander.com (8.9.3/8.9.3) with ESMTP id WAA70898; Thu,
          30 Nov 2000 22:23:30 +0200 (EET) (envelope-from
          Pekka.Nikander@nomadiclab.com)
X-Mailer: Mozilla 4.75C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC)
X-Accept-Language: en
MIME-Version: 1.0
References: <DFF2EFB82ADBD311B4BB00508B6F0C5C0176D305@il27exm03.cig.mot.com>
            <017301c05b04$23cda390$923ba78f@Mobile1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Approved-By:  Pekka Nikander <Pekka.Nikander@NOMADICLAB.COM>
Message-ID:  <3A280324.582B427F@nomadiclab.com>
Date:         Fri, 1 Dec 2000 21:59:32 +0200
Reply-To: Pekka Nikander <Pekka.Nikander@nomadiclab.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pekka Nikander <Pekka.Nikander@nomadiclab.com>
Subject:      Re: [MOBILE-IP] draft agenda (about Homeless draft)
X-cc:         cnyap <cny@ieee.org>,
              bengt.sahlin@ericsson.fi, janne.lundberg@hut.fi,
              catharina.candolin@hut.fi, tuomas.aura@hut.fi
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

cnyap wrote:

> I wonder is "Mobile IP v6 for the Homeless" in charter of working group.

Well, I assume I am biased to answer (since I am the main author of the
draft), but the charter says:

  "The Mobile IP method supports transparency above the IP layer,
   including the maintenance of active TCP connections and UDP port bindings"

The Homeless Mobile IPv6 draft addresses exactly this point, and in a way
  a) that is backward compatible with the current Mobile IPv6 draft,
  b) that is more efficient in what comes to the average IPv6 header size,
  c) that provides better support for multi-homed mobile hosts (aka
     multi-access), host renumbering, and load balancing over several
     parallel links, and
  d) does not _require_ any changes to the wire protocol, even though
     we do propose some small extensions.
Furthermore, it MAY work without explicit home agents (hence the name),
using something like Dynamic DNS to get the initial address of a host.
Once the address is got, it keeps track of movement using Binding Updates,
more or less just like the current Mobile IPv6 draft.  Even though we
do not mention it in the current draft, I don't see any
techical reason why it could not work with home agents as well.
On the other hand, since our primary goal was to device a protocol
that would be more or less "Mobile IPv6 for ad hoc networks", we
wanted to make a solution that can work without home agents.

Now, the draft proposes a small (but significant) change to the
IP semantics.  Based on our analysis and experimentation, most (but
not all) applications will not notice this change at all.  However,
one of the reasons for publishing the draft is that maybe someone
would come along a method that would allow full backward compatibility
for all applications. We have some ideas, but we haven't tested the yet.

Thus, we'd like to raise some discussion about whether it would be
beneficial to possibly make a small change to the Mobile IPv6
semantics, at some later point, in order to gain the benefits mentioned
above.  At least we think that the issue is worth experimenting, and
we are releasing our prototype implementation as soon as it is stable
enough to be used by others.  On the other hand, if any of you have
already considered the method we describe, and found out why it would
not work, we'd be more than happy to know.  So far, we haven't found
anyting that would be exactly the same approach in any proposals.

--Pekka Nikander


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 30 15:46:36 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09427
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Nov 2000 15:46:35 -0500 (EST)
Received: from standards (47.234.32.16:4939) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD65F@standards.nortelnetworks.com>; Thu, 30 Nov 2000 15:27:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 149219 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 15:27:22
          -0500
Received: from patan.sun.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBD65D@standards.nortelnetworks.com>;
          Thu, 30 Nov 2000 15:27:22 -0500
Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com
          (8.9.3+Sun/8.9.3) with ESMTP id MAA12475 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30 Nov 2000 12:44:43
          -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          MAA01855 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30 Nov
          2000 12:44:42 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id MAA01761 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30 Nov 2000 12:44:40
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Pat Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.975616901.29857.pcalhoun@nasnfs>
Date:         Thu, 30 Nov 2000 12:41:41 -0800
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      [MOBILE-IP] draft-shim-mobileip-neighbor-00.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

[disclaimer: I have yet to really read through this document]

Are there particular features required, and documented in this I-D, that are
missing from either the pro-active FA, or the fast handoff proposals? I though
the agreement in the WG for v4 was to have a single proposal, based on either
of the two that resulted from the design team.

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 30 16:02:58 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15230
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Nov 2000 16:02:57 -0500 (EST)
Received: from standards (47.234.32.16:4939) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD6A2@standards.nortelnetworks.com>; Thu, 30 Nov 2000 15:43:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 149306 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 15:43:45
          -0500
Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBD6A0@standards.nortelnetworks.com>; Thu, 30 Nov 2000 15:43:44
          -0500
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA27354 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30 Nov 2000 14:01:05
          -0700 (MST)]
Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102])
          by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA15707 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30 Nov 2000 14:01:05
          -0700 (MST)]
Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id
          <WMS1HY5C>; Thu, 30 Nov 2000 15:01:04 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain
Approved-By:  Roberts Philip-qa3445 <Philip_Roberts-qa3445@EMAIL.MOT.COM>
Message-ID:  <DFF2EFB82ADBD311B4BB00508B6F0C5C02B1EFE7@il27exm03.cig.mot.com>
Date:         Thu, 30 Nov 2000 15:01:02 -0600
Reply-To: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Roberts Philip-qa3445 <Philip_Roberts-qa3445@email.mot.com>
Subject:      Re: [MOBILE-IP] draft-shim-mobileip-neighbor-00.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I'd like to help set some expectations for the working group on new handover submissions.  The goal we set for ourselves in Pittsburgh was to produce a single working group document on fast handover support for IP v4 and a single working group document on fast handover for IP v6.  To that end, two design teams were formed, one for v4 and one for v6.  The v4 team completed its work a couple of months ago with 2 documents.  The goal in San Diego is for the working group to make a decision about those two.  New handover proposals need to be evaluated in the light of those two and whether what needs to be done can be done with one of those two.  Once we pick one of those, new handover submissions on v4 should really have in mind how to add or extend the one that is chosen.

The v6 design team has produced a single draft.  (I'm a little more reserved here as Raj has been monitoring that team more than I).  Proposals for handover in v6 need to first consider whether what is desired is not already covered by that document.

Although all submissions are welcomed, the work of the design teams have a sort of pride of place, moreso once we agree to make the respective documents working group documents.

Phil


> ----------
> From:         Pat Calhoun
> Reply To:     Pat Calhoun
> Sent:         Friday, December 1, 2000 4:41 AM
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      [MOBILE-IP] draft-shim-mobileip-neighbor-00.txt
>
> [disclaimer: I have yet to really read through this document]
>
> Are there particular features required, and documented in this I-D, that are
> missing from either the pro-active FA, or the fast handoff proposals? I though
> the agreement in the WG for v4 was to have a single proposal, based on either
> of the two that resulted from the design team.
>
> PatC
>
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 30 18:05:59 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13986
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Nov 2000 18:05:58 -0500 (EST)
Received: from standards (47.234.32.16:1396) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD77E@standards.nortelnetworks.com>; Thu, 30 Nov 2000 17:46:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 149590 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 17:46:45
          -0500
Received: from patan.sun.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBD77C@standards.nortelnetworks.com>;
          Thu, 30 Nov 2000 17:46:45 -0500
Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com
          (8.9.3+Sun/8.9.3) with ESMTP id PAA05720 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30 Nov 2000 15:04:01
          -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          PAA20416 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30 Nov
          2000 15:04:01 -0800 (PST)
Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id PAA05175; Thu, 30 Nov 2000 15:03:59
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 46CI7CWsIscJkDg0/ONdOQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc
Approved-By:  James Kempf <James.Kempf@ENG.SUN.COM>
Message-ID:  <200011302303.PAA05175@nasnfs.eng.sun.com>
Date:         Thu, 30 Nov 2000 15:03:32 -0800
Reply-To: James Kempf <James.Kempf@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: James Kempf <James.Kempf@Eng.Sun.COM>
Subject:      [MOBILE-IP] Pro-active Handoff and FA Location
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi folks,

I've been told that, while I was offline, there was a discussion of whether
pro-active FA handoff would require co-location of the FA and an 802.11
access point because of the need for link layer triggers.

In fact, there is a protocol for interaccess point communication in 802.11
(InterAccess Point Protocol, IAPP) that was presented to the IETF in 1998 but
was turned down because it was too 802.11 specific, that, I believe,
has been picked up by IEEE. This protocol allows access points to
announce themselves when they come on line, and to send out handover
information on the wired backbone when a mobile moves from one access point to
another (which the mobile can do in 802.11 on its own). I have an old copy of
the spec if anybody cares to look at it.

An FA that was located away from an access point could tap into this
information and use the IAPP Handover message as an "L2" trigger to
determine when an L2 handoff was occuring. This would fit in directly
to the "post trigger" scenario described in the pro-active draft.

Note that the term "L2 trigger" in the pro-active handoff draft
may be somewhat misleading as, even in such systems as IS-2000 CDMA,
the protocol stacks involved in control in the RAN are not really
L2, they are SS7 style stacks with control protocols running
at the application layer. The control protocol in the IS-2000 case
would probably be something like IS-634 (IOS 4.0) or maybe IS-41, which
is pretty far above the L2 layer. From the point of view of the FA, however,
they might as well be at L2, since they are not running on IP networks. At any
rate, the IAPP Handover message for 802.11 would be exactly analogous to, say,
an IS-41 Handover Request message, both of which would generate a proactive
Handover Request message, except the IAPP message is a post trigger
while the IS-41 message is a pre trigger.

Apologies if this duplicated any discussion previously on the list.

                jak


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 30 18:31:54 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27017
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Nov 2000 18:31:53 -0500 (EST)
Received: from standards (47.234.32.16:1396) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD7D4@standards.nortelnetworks.com>; Thu, 30 Nov 2000 18:12:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 149703 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 18:12:40
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:53942) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBD7D2@standards.nortelnetworks.com>; Thu, 30 Nov 2000
          18:12:39 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id KAA09030 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 1 Dec 2000 10:26:26
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id KAA24203 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 1 Dec 2000 10:29:18
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD9SXB>; Fri, 1 Dec 2000 10:29:36 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613ED9@eaubrnt018.epa.ericsson.se>
Date:         Fri, 1 Dec 2000 10:29:34 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] Pro-active Handoff and FA Location
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi James,

Good point , but I have a question and a comment below.


> I've been told that, while I was offline, there was a discussion of
> whether
> pro-active FA handoff would require co-location of the FA and an 802.11
> access point because of the need for link layer triggers.
>
> In fact, there is a protocol for interaccess point communication in 802.11
> (InterAccess Point Protocol, IAPP) that was presented to the IETF in 1998
> but
> was turned down because it was too 802.11 specific, that, I believe,
> has been picked up by IEEE. This protocol allows access points to
> announce themselves when they come on line, and to send out handover
> information on the wired backbone when a mobile moves from one access
> point to
> another (which the mobile can do in 802.11 on its own). I have an old copy
> of
> the spec if anybody cares to look at it.
>
> An FA that was located away from an access point could tap into this
> information and use the IAPP Handover message as an "L2" trigger to
> determine when an L2 handoff was occuring. This would fit in directly
> to the "post trigger" scenario described in the pro-active draft.
>
        => My understanding of this protocol (correct me if I'm wrong)
        is that it works between APs connected on the same subnet.
        Hence the FA on the current subnet will not be aware of the
        movement of the MN to the new subnet. I realise that you
        mentioned the "post trigger". I assume you mean that after
        the movement, the new FA would tap into the IAPP protocol
        to know the MAC address of the MN that just turned up and
        "somehow" notify the old FA ?
        If that is correct then I have a couple of points to make :

        1. How does the new FA know where the MN came from ?
        Knowing the MAC address doesn't help

        2. Even if somehow the FA can determine this, the handover
        in this cases is not very fast as no anticipation was done
        (as opposed to the case where the current FA knows
        that the MN is about to move).
        So what would happen is:
        a) The MN moves
        b) The FA somehow knows this and knows where it came
            from
        c) The new FA requests forwarding of packets from the old
             FA. In the mean time all packets are not delivered
            or are lost over the old air interface.


        Finally, the use of WLAN was an example of the architectural
        limitation. My point was that there are cases where the FA
        may not have that knowledge (the MNs future movement)
        so in these scenarios a complete network control does not
        help. That is IMO one of the fundamental differences between
        the two proposals. FH follows RFC 2002 and simply reorders
        the actions (new adv from the old FA)  and the MN requests
bicasting.
        So the control of handoff is still shared between the MN and
        the terminal. Hence more flexibility and less architectural
        dependance.

        Regards,
        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 30 18:54:23 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08406
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Nov 2000 18:54:23 -0500 (EST)
Received: from standards (47.234.32.16:1396) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD82F@standards.nortelnetworks.com>; Thu, 30 Nov 2000 18:35:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 149822 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 18:35:10
          -0500
Received: from patan.sun.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBD82D@standards.nortelnetworks.com>;
          Thu, 30 Nov 2000 18:35:10 -0500
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com
          (8.9.3+Sun/8.9.3) with ESMTP id PAA16586; Thu, 30 Nov 2000 15:52:25
          -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          PAA04095; Thu, 30 Nov 2000 15:52:24 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id PAA06205; Thu, 30 Nov 2000 15:52:19
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Pat Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.975628160.754.pcalhoun@nasnfs>
Date:         Thu, 30 Nov 2000 15:49:20 -0800
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Pro-active Handoff and FA Location
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <4B6BC00CD15FD2119E5F0008C7A419A50C613ED9@eaubrnt018.epa.ericsson.se>

> Hi James,
>
> Good point , but I have a question and a comment below.
>
>
> > I've been told that, while I was offline, there was a discussion of
> > whether
> > pro-active FA handoff would require co-location of the FA and an 802.11
> > access point because of the need for link layer triggers.
> >
> > In fact, there is a protocol for interaccess point communication in 802.11
> > (InterAccess Point Protocol, IAPP) that was presented to the IETF in 1998
> > but
> > was turned down because it was too 802.11 specific, that, I believe,
> > has been picked up by IEEE. This protocol allows access points to
> > announce themselves when they come on line, and to send out handover
> > information on the wired backbone when a mobile moves from one access
> > point to
> > another (which the mobile can do in 802.11 on its own). I have an old copy
> > of
> > the spec if anybody cares to look at it.
> >
> > An FA that was located away from an access point could tap into this
> > information and use the IAPP Handover message as an "L2" trigger to
> > determine when an L2 handoff was occuring. This would fit in directly
> > to the "post trigger" scenario described in the pro-active draft.
> >
>         => My understanding of this protocol (correct me if I'm wrong)
>         is that it works between APs connected on the same subnet.
>         Hence the FA on the current subnet will not be aware of the
>         movement of the MN to the new subnet. I realise that you
>         mentioned the "post trigger". I assume you mean that after
>         the movement, the new FA would tap into the IAPP protocol
>         to know the MAC address of the MN that just turned up and
>         "somehow" notify the old FA ?
>         If that is correct then I have a couple of points to make :
>
>         1. How does the new FA know where the MN came from ?
>         Knowing the MAC address doesn't help

I believe that Jim meant to state that the APs would forward IAPP messages to
the FAs as well. This way the FAs would be aware of handoffs. This, of course,
is not typically done today.

>
>         2. Even if somehow the FA can determine this, the handover
>         in this cases is not very fast as no anticipation was done
>         (as opposed to the case where the current FA knows
>         that the MN is about to move).
>         So what would happen is:
>         a) The MN moves
>         b) The FA somehow knows this and knows where it came
>             from
>         c) The new FA requests forwarding of packets from the old
>              FA. In the mean time all packets are not delivered
>             or are lost over the old air interface.
IAPP provides all you need. Again, this is ONLY needed for implementations
that DO NOT colocate FA and APs. Keep in mind that although this is not a
popular combination today, the demand for fast handoffs will force vendors to
combine these features.

>
>
>         Finally, the use of WLAN was an example of the architectural
>         limitation. My point was that there are cases where the FA
>         may not have that knowledge (the MNs future movement)
>         so in these scenarios a complete network control does not
>         help. That is IMO one of the fundamental differences between
>         the two proposals. FH follows RFC 2002 and simply reorders
>         the actions (new adv from the old FA)  and the MN requests
> bicasting.
>         So the control of handoff is still shared between the MN and
>         the terminal. Hence more flexibility and less architectural
>         dependance.

Hesham, it seems as if I've missed something here. You keep stating that
pro-active FA would not work because the AP is not part of the FA (which again
I state is really an implementation issue).

However, the "fast handoff" proposal supports two methods of providing faster
handoffs: 1. Inter-FA Solicitation
        Now in order for this scheme to work, the FA will HAVE to receive a layer
        two trigger of some form, so it is subject to the same problem as
        the pro-active FA proposal (where colocation is required).
2. Piggy-backing Advertisements on L2 messaging
        Now this proposal requires link layer changes, so we are back to square
        one. If link layer changes are required, then I see no reason why #1
        cannot be done (using either proposal).

So I am quite confused when you state that pro-active has some inherent
problems with 802.11. I really don't see either of our proposals are being ANY
different from each other in this regard.

Furthermore, for APs that do not colocate FA, or do something else to get fast
handoff, then mobiles get RFC2002. Let the market demand for fast handoff
drive colocation of APs and FA. Let's not dwell on this one...

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 30 19:05:51 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13075
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Nov 2000 19:05:51 -0500 (EST)
Received: from standards (47.234.32.16:1396) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD87F@standards.nortelnetworks.com>; Thu, 30 Nov 2000 18:46:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 149925 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 18:46:21
          -0500
Received: from patan.sun.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBD87D@standards.nortelnetworks.com>;
          Thu, 30 Nov 2000 18:46:21 -0500
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com
          (8.9.3+Sun/8.9.3) with ESMTP id QAA27397 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30 Nov 2000 16:03:42
          -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          QAA08133; Thu, 30 Nov 2000 16:03:41 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id QAA06530; Thu, 30 Nov 2000 16:03:36
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Pat Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.975628837.23660.pcalhoun@nasnfs>
Date:         Thu, 30 Nov 2000 16:00:37 -0800
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject:      Re: [MOBILE-IP] Pro-active Handoff and FA Location
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <Roam.SIMC.2.0.6.975628160.754.pcalhoun@nasnfs>

> 2. Piggy-backing Advertisements on L2 messaging
>         Now this proposal requires link layer changes, so we are back to
> square
>         one. If link layer changes are required, then I see no reason why #1
>         cannot be done (using either proposal).

Let me rephrase this one. If link layer changes are required, then we are back
to the e-mail you and Ajoy exchanged to requiring link layer changes for
non-colocated APs/FAs.

So in either proposal, the amount of effort is the same.

Keep in mind, however, the fast handoff will NOT work in environments that do
not provide sufficient time for mobiles to participate in the handoff.

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 30 19:05:53 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13079
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Nov 2000 19:05:52 -0500 (EST)
Received: from standards (47.234.32.16:1396) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD883@standards.nortelnetworks.com>; Thu, 30 Nov 2000 18:46:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 149929 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 18:46:24
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:54934) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBD881@standards.nortelnetworks.com>; Thu, 30 Nov 2000
          18:46:22 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA11977 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 1 Dec 2000 11:00:13
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA29645 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 1 Dec 2000 11:03:05
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD94D8>; Fri, 1 Dec 2000 11:03:23 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613EDA@eaubrnt018.epa.ericsson.se>
Date:         Fri, 1 Dec 2000 11:03:20 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] Pro-active Handoff and FA Location
X-To:         Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> > >
> > > An FA that was located away from an access point could tap into this
> > > information and use the IAPP Handover message as an "L2" trigger to
> > > determine when an L2 handoff was occuring. This would fit in directly
> > > to the "post trigger" scenario described in the pro-active draft.
> > >
> >         => My understanding of this protocol (correct me if I'm wrong)
> >         is that it works between APs connected on the same subnet.
> >         Hence the FA on the current subnet will not be aware of the
> >         movement of the MN to the new subnet. I realise that you
> >         mentioned the "post trigger". I assume you mean that after
> >         the movement, the new FA would tap into the IAPP protocol
> >         to know the MAC address of the MN that just turned up and
> >         "somehow" notify the old FA ?
> >         If that is correct then I have a couple of points to make :
> >
> >         1. How does the new FA know where the MN came from ?
> >         Knowing the MAC address doesn't help
>
> I believe that Jim meant to state that the APs would forward IAPP messages
> to
> the FAs as well. This way the FAs would be aware of handoffs. This, of
> course,
> is not typically done today.
>
        =>

> >
> >         2. Even if somehow the FA can determine this, the handover
> >         in this cases is not very fast as no anticipation was done
> >         (as opposed to the case where the current FA knows
> >         that the MN is about to move).
> >         So what would happen is:
> >         a) The MN moves
> >         b) The FA somehow knows this and knows where it came
> >             from
> >         c) The new FA requests forwarding of packets from the old
> >              FA. In the mean time all packets are not delivered
> >             or are lost over the old air interface.
> IAPP provides all you need. Again, this is ONLY needed for implementations
> that DO NOT colocate FA and APs. Keep in mind that although this is not a
> popular combination today, the demand for fast handoffs will force vendors
> to
> combine these features.
>
> >
> >
> >         Finally, the use of WLAN was an example of the architectural
> >         limitation. My point was that there are cases where the FA
> >         may not have that knowledge (the MNs future movement)
> >         so in these scenarios a complete network control does not
> >         help. That is IMO one of the fundamental differences between
> >         the two proposals. FH follows RFC 2002 and simply reorders
> >         the actions (new adv from the old FA)  and the MN requests
> > bicasting.
> >         So the control of handoff is still shared between the MN and
> >         the terminal. Hence more flexibility and less architectural
> >         dependance.
>
> Hesham, it seems as if I've missed something here. You keep stating that
> pro-active FA would not work because the AP is not part of the FA (which
> again
> I state is really an implementation issue).
>
> However, the "fast handoff" proposal supports two methods of providing
> faster
> handoffs: 1. Inter-FA Solicitation
>       Now in order for this scheme to work, the FA will HAVE to receive a
> layer
>       two trigger of some form, so it is subject to the same problem as
>       the pro-active FA proposal (where colocation is required).
> 2. Piggy-backing Advertisements on L2 messaging
>       Now this proposal requires link layer changes, so we are back to
> square
>       one. If link layer changes are required, then I see no reason why #1
>       cannot be done (using either proposal).
>
> So I am quite confused when you state that pro-active has some inherent
> problems with 802.11. I really don't see either of our proposals are being
> ANY
> different from each other in this regard.
>
> Furthermore, for APs that do not colocate FA, or do something else to get
> fast
> handoff, then mobiles get RFC2002. Let the market demand for fast handoff
> drive colocation of APs and FA. Let's not dwell on this one...
>
> PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 30 19:28:34 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21474
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Nov 2000 19:28:33 -0500 (EST)
Received: from standards (47.234.32.16:1396) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD944@standards.nortelnetworks.com>; Thu, 30 Nov 2000 19:09:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 150184 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 19:09:13
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:55643) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBD942@standards.nortelnetworks.com>; Thu, 30 Nov 2000
          19:09:11 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA14152 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 1 Dec 2000 11:23:02
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA03204 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 1 Dec 2000 11:25:54
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD947M>; Fri, 1 Dec 2000 11:26:10 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613EDB@eaubrnt018.epa.ericsson.se>
Date:         Fri, 1 Dec 2000 11:26:06 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] Pro-active Handoff and FA Location
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

        Sorry for the last mail. I do actually have something to say :)

> > > In fact, there is a protocol for interaccess point communication in
> 802.11
> > > (InterAccess Point Protocol, IAPP) that was presented to the IETF in
> 1998
> > > but
> > > was turned down because it was too 802.11 specific, that, I believe,
> > > has been picked up by IEEE. This protocol allows access points to
> > > announce themselves when they come on line, and to send out handover
> > > information on the wired backbone when a mobile moves from one access
> > > point to
> > > another (which the mobile can do in 802.11 on its own). I have an old
> copy
> > > of
> > > the spec if anybody cares to look at it.
> > >
> > > An FA that was located away from an access point could tap into this
> > > information and use the IAPP Handover message as an "L2" trigger to
> > > determine when an L2 handoff was occuring. This would fit in directly
> > > to the "post trigger" scenario described in the pro-active draft.
> > >
> >         => My understanding of this protocol (correct me if I'm wrong)
> >         is that it works between APs connected on the same subnet.
> >         Hence the FA on the current subnet will not be aware of the
> >         movement of the MN to the new subnet. I realise that you
> >         mentioned the "post trigger". I assume you mean that after
> >         the movement, the new FA would tap into the IAPP protocol
> >         to know the MAC address of the MN that just turned up and
> >         "somehow" notify the old FA ?
> >         If that is correct then I have a couple of points to make :
> >
> >         1. How does the new FA know where the MN came from ?
> >         Knowing the MAC address doesn't help
>
> I believe that Jim meant to state that the APs would forward IAPP messages
> to
> the FAs as well. This way the FAs would be aware of handoffs. This, of
> course,
> is not typically done today.
>
        => Yes I understand. But the APs will forward this information to
        the FA they are connected to _only_. My understanding is that
        the MN does not tell the old AP "I'm leaving now to go to AP X".
        The AP's update each other after the MN has moved to their
        respective coverage areas to avoid packets being sent over
        multiple radio interfaces.  So based on my understanding
        I can't see how the "current" FA would know that the MN
        is moving. In addition the new FA has no way of knowing
        where the MN came from even if it listens to IAPP.


> >
> >         2. Even if somehow the FA can determine this, the handover
> >         in this cases is not very fast as no anticipation was done
> >         (as opposed to the case where the current FA knows
> >         that the MN is about to move).
> >         So what would happen is:
> >         a) The MN moves
> >         b) The FA somehow knows this and knows where it came
> >             from
> >         c) The new FA requests forwarding of packets from the old
> >              FA. In the mean time all packets are not delivered
> >             or are lost over the old air interface.
> IAPP provides all you need.
>
        => Perhaps an answer to my question above would make it
        clearer.

> Again, this is ONLY needed for implementations
> that DO NOT colocate FA and APs. Keep in mind that although this is not a
> popular combination today, the demand for fast handoffs will force vendors
> to
> combine these features.
>
        => I'm not disagreeing, but I want to emphasise that this is
        an example to express my point, being architectural dependancy.

> >
> >
> >         Finally, the use of WLAN was an example of the architectural
> >         limitation. My point was that there are cases where the FA
> >         may not have that knowledge (the MNs future movement)
> >         so in these scenarios a complete network control does not
> >         help. That is IMO one of the fundamental differences between
> >         the two proposals. FH follows RFC 2002 and simply reorders
> >         the actions (new adv from the old FA)  and the MN requests
> > bicasting.
> >         So the control of handoff is still shared between the MN and
> >         the terminal. Hence more flexibility and less architectural
> >         dependance.
>
> Hesham, it seems as if I've missed something here. You keep stating that
> pro-active FA would not work because the AP is not part of the FA (which
> again
> I state is really an implementation issue).
>
        => I respectfully disagree. I would say it's an architectural issue.


> However, the "fast handoff" proposal supports two methods of providing
> faster
> handoffs: 1. Inter-FA Solicitation
>       Now in order for this scheme to work, the FA will HAVE to receive a
> layer
>       two trigger of some form, so it is subject to the same problem as
>       the pro-active FA proposal (where colocation is required).
> 2. Piggy-backing Advertisements on L2 messaging
>       Now this proposal requires link layer changes, so we are back to
> square
>       one. If link layer changes are required, then I see no reason why #1
>       cannot be done (using either proposal).
>
> So I am quite confused when you state that pro-active has some inherent
> problems with 802.11. I really don't see either of our proposals are being
> ANY
> different from each other in this regard.
>
        => I agree that the two proposals are very similar. They both
support
        simultaneous bindings and other similar concepts.
        Apart from the list of differences we discussed, I see a difference
        in the dependancy on certain architectures. You might think that
        this is an implementation issue, but it's important to highlight it.

        In some cases the changes required to support the assumed
        architecture may not be trivial.

        Regards,
        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 30 19:44:09 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26755
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Nov 2000 19:44:08 -0500 (EST)
Received: from standards (47.234.32.16:1396) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD99D@standards.nortelnetworks.com>; Thu, 30 Nov 2000 19:24:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 150302 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 19:24:52
          -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBD99B@standards.nortelnetworks.com>; Thu, 30 Nov 2000 19:24:51
          -0500
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id QAA08114; Thu, 30 Nov 2000 16:42:09
          -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          QAA18046; Thu, 30 Nov 2000 16:42:04 -0800 (PST)
Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id QAA07311; Thu, 30 Nov 2000 16:41:56
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Approved-By:  Pat Calhoun <Pat.Calhoun@ENG.SUN.COM>
Message-ID:  <Roam.SIMC.2.0.6.975631137.22205.pcalhoun@nasnfs>
Date:         Thu, 30 Nov 2000 16:38:57 -0800
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Pro-active Handoff and FA Location
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <4B6BC00CD15FD2119E5F0008C7A419A50C613EDB@eaubrnt018.epa.ericsson.se>

>         => I agree that the two proposals are very similar. They both
> support
>         simultaneous bindings and other similar concepts.
>         Apart from the list of differences we discussed, I see a difference
>         in the dependancy on certain architectures. You might think that
>         this is an implementation issue, but it's important to highlight it.
>
>         In some cases the changes required to support the assumed
>         architecture may not be trivial.

Correct, but the design choices made also allow the proposal to be used with
even the strictest of link layers (ones that INFORM the mobile that a handoff
is in process). In these wireless networks, there is no additional time for
Mobile IP registration.

However, you failed to address my comment where I stated that this co-location
issue is NOT a pro-active problem, since the fast handoff proposal uses
similar triggers. Both proposals require colocated AP/FAs.

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 30 20:10:13 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05554
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Nov 2000 20:10:13 -0500 (EST)
Received: from standards (47.234.32.16:1963) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD9F2@standards.nortelnetworks.com>; Thu, 30 Nov 2000 19:50:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 150413 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 19:50:55
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111:57033) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBD9F0@standards.nortelnetworks.com>; Thu, 30 Nov 2000
          19:50:54 -0500
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id MAA18251 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 1 Dec 2000 12:04:44
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA09521 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 1 Dec 2000 12:07:37
          +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <WRBD9WJ4>; Fri, 1 Dec 2000 12:07:54 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Approved-By:  "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50C613EDD@eaubrnt018.epa.ericsson.se>
Date:         Fri, 1 Dec 2000 12:07:52 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
Subject:      Re: [MOBILE-IP] Pro-active Handoff and FA Location
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> >         => I agree that the two proposals are very similar. They both
> > support
> >         simultaneous bindings and other similar concepts.
> >         Apart from the list of differences we discussed, I see a
> difference
> >         in the dependancy on certain architectures. You might think that
> >         this is an implementation issue, but it's important to highlight
> it.
> >
> >         In some cases the changes required to support the assumed
> >         architecture may not be trivial.
>
> Correct, but the design choices made also allow the proposal to be used
> with
> even the strictest of link layers (ones that INFORM the mobile that a
> handoff
> is in process).
>
        => These link layers are much more sophisticated than others
        because they know where the MN is going. I think that makes
        it easier to accomodate MIP since you're getting good hints.
        FH also supports that case by sending the proxy advertisement
        to the MN from the current FA.

> In these wireless networks, there is no additional time for
> Mobile IP registration.
>
        => Which wireless links ? CDMA for example ?
        As we mentioned during the meetings, we looked at these
        handoff sequences and found that there is time and it is
        certainly possible to support FH. CDMA is much more
        flexible in terms of handoff times than other wireless
        systems.

> However, you failed to address my comment where I stated that this
> co-location
> issue is NOT a pro-active problem, since the fast handoff proposal uses
> similar triggers. Both proposals require colocated AP/FAs.
>
        => The FH model allows for both MN initiation and FA initiation.
Therefore
        I don't see why it would need this colocation.
        You also didn't answer my comments on IAPP :)

        Hesham


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 30 22:17:54 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23115
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Nov 2000 22:17:53 -0500 (EST)
Received: from standards (47.234.32.16:4701) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDA98@standards.nortelnetworks.com>; Thu, 30 Nov 2000 21:58:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 150630 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 21:58:30
          -0500
Received: from hotmail.com (law2-f211.hotmail.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBDA96@standards.nortelnetworks.com>; Thu, 30 Nov 2000
          21:58:29 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu,
          30 Nov 2000 19:15:51 -0800
Received: from 158.252.161.100 by lw2fd.hotmail.msn.com with HTTP; Fri, 01 Dec
          2000 03:15:51 GMT
X-Originating-IP: [158.252.161.100]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 01 Dec 2000 03:15:51.0590 (UTC)
                       FILETIME=[024DD460:01C05B45]
Approved-By:  Ladipo Adefala <ladefala@HOTMAIL.COM>
Message-ID:  <LAW2-F211Xm8P4ALDEF00007838@hotmail.com>
Date:         Fri, 1 Dec 2000 04:15:51 +0100
Reply-To: Ladipo Adefala <ladefala@hotmail.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ladipo Adefala <ladefala@hotmail.com>
Subject:      Re: [MOBILE-IP] Pro-active Handoff and FA Location
X-To:         Hesham.Soliman@ericsson.com.au
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Could someone please remind me of the process to remove myself from this
mailing list.
Thanks


>From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
>Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
>To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
>Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location
>Date: Fri, 1 Dec 2000 12:07:52 +1100
>
> > >         => I agree that the two proposals are very similar. They both
> > > support
> > >         simultaneous bindings and other similar concepts.
> > >         Apart from the list of differences we discussed, I see a
> > difference
> > >         in the dependancy on certain architectures. You might think
>that
> > >         this is an implementation issue, but it's important to
>highlight
> > it.
> > >
> > >         In some cases the changes required to support the assumed
> > >         architecture may not be trivial.
> >
> > Correct, but the design choices made also allow the proposal to be used
> > with
> > even the strictest of link layers (ones that INFORM the mobile that a
> > handoff
> > is in process).
> >
>         => These link layers are much more sophisticated than others
>         because they know where the MN is going. I think that makes
>         it easier to accomodate MIP since you're getting good hints.
>         FH also supports that case by sending the proxy advertisement
>         to the MN from the current FA.
>
> > In these wireless networks, there is no additional time for
> > Mobile IP registration.
> >
>         => Which wireless links ? CDMA for example ?
>         As we mentioned during the meetings, we looked at these
>         handoff sequences and found that there is time and it is
>         certainly possible to support FH. CDMA is much more
>         flexible in terms of handoff times than other wireless
>         systems.
>
> > However, you failed to address my comment where I stated that this
> > co-location
> > issue is NOT a pro-active problem, since the fast handoff proposal uses
> > similar triggers. Both proposals require colocated AP/FAs.
> >
>         => The FH model allows for both MN initiation and FA initiation.
>Therefore
>         I don't see why it would need this colocation.
>         You also didn't answer my comments on IAPP :)
>
>         Hesham

_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Nov 30 23:26:14 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20378
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Nov 2000 23:26:13 -0500 (EST)
Received: from standards (47.234.32.16:1039) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDAFF@standards.nortelnetworks.com>; Thu, 30 Nov 2000 23:07:00 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 150770 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 23:07:00
          -0500
Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBDAFD@standards.nortelnetworks.com>; Thu, 30 Nov 2000 23:06:59
          -0500
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by
          motgate.mot.com (motgate 2.1) with ESMTP id VAA20159 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30 Nov 2000 21:24:21
          -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100])
          by mothost.mot.com (MOT-mothost 2.0) with ESMTP id VAA03104 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30 Nov 2000 21:24:21
          -0700 (MST)]
Received: from ripcord756 (d50-497f.cig.mot.com [160.47.73.127]) by
          il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2651.58) id WQNKVHHV; Thu, 30 Nov 2000 22:24:15
          -0600
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.00.2314.1300
Approved-By:  Ajoy Singh <asingh1@EMAIL.MOT.COM>
Message-ID:  <NEBBIAJKMGAFBLOHKLJKAEEHCBAA.asingh1@email.mot.com>
Date:         Thu, 30 Nov 2000 22:34:05 -0600
Reply-To: Ajoy Singh <asingh1@email.mot.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ajoy Singh <asingh1@email.mot.com>
Subject:      Re: [MOBILE-IP] Pro-active Handoff and FA Location
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4B6BC00CD15FD2119E5F0008C7A419A50C613EDD@eaubrnt018.epa.ericsson.se>
Content-Transfer-Encoding: 7bit

-----Original Message-----
From: IP Routing for Wireless/Mobile Hosts (mobile-ip)
[mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Hesham
Soliman (EPA)
Sent: Thursday, November 30, 2000 7:08 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location


> >         => I agree that the two proposals are very similar. They both
> > support
> >         simultaneous bindings and other similar concepts.
> >         Apart from the list of differences we discussed, I see a
> difference
> >         in the dependancy on certain architectures. You might think that
> >         this is an implementation issue, but it's important to highlight
> it.
> >
> >         In some cases the changes required to support the assumed
> >         architecture may not be trivial.
>
> Correct, but the design choices made also allow the proposal to be used
> with
> even the strictest of link layers (ones that INFORM the mobile that a
> handoff
> is in process).
>
        => These link layers are much more sophisticated than others
        because they know where the MN is going. I think that makes
        it easier to accomodate MIP since you're getting good hints.
        FH also supports that case by sending the proxy advertisement
        to the MN from the current FA.

> In these wireless networks, there is no additional time for
> Mobile IP registration.
>
        => Which wireless links ? CDMA for example ?
        As we mentioned during the meetings, we looked at these
        handoff sequences and found that there is time and it is
        certainly possible to support FH. CDMA is much more
        flexible in terms of handoff times than other wireless
        systems.

<AS> Are you talking about CDMA soft or hard handoff ? Hard handoff
is break before make and soft handoff is make before break. Mobile/IP is
candidate for hard handoff not soft handoff. In case of hard handoff,
it is not a good idea to add lot of over the air messages which is
required for Mobile/IP FH support. Addition of more over the air
messages will increase the possibility of call drop (due to bad link) which
is worse
than poor handoff performance. BTW, in general wireless link discourages
over the air signaling as much as possible. The signaling channels
are designed to carry small messages. Typically, mobile/IP messages
may take multiple air interface frames if carried over current signaling
channels.
This will add to latency of Mobile/IP handover.  Moreover, bearer channel
for data are scheduled on demand. The bearer channels (SCH) are not
available all the
time during data call.  For example,
in case of real audio type of application only forward channel will be
available
for active user. So if you schedule reverse channel to send Mobile/IP
messages,
it will to add to handover delay because there will some signaling required
to schedule
a channel. This type of dependency is not there in proactive case. In case
of proactive
handoff, Mobile/IP messages are not in critical path, so the user of
proactive approach
will have lesser chance of call drop during handover. The cases where you
will
have dedicated channel for bearer traffic, this problem may not be that bad.
I
hate to talk about CDMA or any other link layer in Mobile/IP list, but
we want a solution that should work for all wireless links. Unfortunately,
I do not see fast handoff approach working all the time for all wireless
links. <AS>


> However, you failed to address my comment where I stated that this
> co-location
> issue is NOT a pro-active problem, since the fast handoff proposal uses
> similar triggers. Both proposals require colocated AP/FAs.
>
        => The FH model allows for both MN initiation and FA initiation.
Therefore
        I don't see why it would need this colocation.
        You also didn't answer my comments on IAPP :)

        Hesham